Возможно, я не понимаю, как это должно работать, но я не могу понять, почему система РЕЗЕРВНОГО КОПИРОВАНИЯ с этим базовым vrrp_instance сразу же переходит в мастерскую и, кажется, никогда не соблюдает приоритет.
Почему бы виртуальному IP-адресу не выпадать из системы резервного копирования, когда и то, и другое исправно и подключено к сети?
Похоже, обе системы транслируют рекламу vrrp. Из tcpdump в системе резервного копирования:
betaproxyslc01.fakecorp.com> vrrp.mcast.net: vrrp betaproxyslc01.fakecorp.com> vrrp.mcast.net: VRRPv2, Реклама, vrid 51, prio 150, authtype simple, intvl 1s, length 20,> addrs: virtual-app.fakecorp.com auth "пароль" 15: 52: 24.541637 IP (tos 0xc0, ttl 255, id 1611, смещение 0, флаги [нет], протокол VRRP (112), длина 40)
betaproxyslc02.fakecorp.com> vrrp.mcast.net: vrrp betaproxyslc02.fakecorp.com> vrrp.mcast.net: VRRPv2, Реклама, vrid 51, prio 100, authtype simple, intvl 1s, length 20,> addrs: virtual-app.fakecorp.com auth "пароль" 15: 52: 25.410073 IP (tos 0xc0, ttl 255, id 1779, смещение 0, флаги [нет], протокол VRRP (112), длина 40)
но виртуальный IP-адрес отображается на обоих хостах с ip addr команда.
Вот конфиг:
global_defs {
notification_email {
me@fakecorp.com
}
notification_email_from keepalived@betaproxyslc01.fakecorp.com
smtp_server mysmtpserver.fakecorp.com
smtp_connect_timeout 30
router_id BETAPROXYSLC01
}
vrrp_script chk_haproxy{
script "killall -0 haproxy"
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
notify /usr/local/bin/notify.sh
authentication {
auth_type PASS
auth_pass keep0ut!
}
virtual_ipaddress {
10.10.0.40
}
track_script{
chk_haproxy
}
}
На сервере BACKUP другой router_id, состояние BACKUP и приоритет 100. Остальные настройки такие же.
Это при установке CentOS 7 с Keepalived v1.2.10 (06.10.2014), гостевой виртуальной машине Hyper-V с ядром 3.10.0-123.8.1.el7.x86_64.
Для связи VRRP между маршрутизаторами используется групповой IP-адрес 224.0.0.18.[1] и номер протокола IP 112[2].
Таким образом, вам нужно только разрешить входящий и исходящий трафик с этими конкретными параметрами для правильной работы VRRP. Обычно упоминаемые правила брандмауэра избыточны и излишне широко сформулированы.
Я предлагаю вам использовать эти правила брандмауэра:
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 0 --out-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --reload
[1] http://tools.ietf.org/html/rfc5798#section-5.1.1.2
[2] http://tools.ietf.org/html/rfc5798#section-5.1.1.4
Ссылка на информацию брандмауэра в конце эта страница Мне удалось заставить его работать, открыв брандмауэр с помощью:
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -i eth0 -d 224.0.0.0/8 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter INPUT 0 -i eth0 -d 224.0.0.0/8 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p vrrp -i eth0 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter INPUT 0 -p vrrp -i eth0 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -p vrrp -o eth0 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter OUTPUT 0 -p vrrp -o eth0 -j ACCEPT
Казалось, нужны только первые (два) варианта. Как только я установил правило для приема трафика на многоадресный адрес, система резервного копирования обнаружила трафик vrrp, вернулась в режим резервного копирования и отозвала VIP. Я полагаю, что меня смутило то, что я мог видеть многоадресный трафик из обеих систем на обеих системах с помощью tcpdump.