VIP не выпадает из резервной копии

Возможно, я не понимаю, как это должно работать, но я не могу понять, почему система BACKUP с этим базовым vrrp_instance сразу переходит к мастеру и, кажется, никогда не выполняет приоритет.

Почему виртуальный IP-адрес не будет сброшен системой резервного копирования, если оба исправны и подключены к сети?

Похоже, обе системы транслируют рекламу vrrp. От tcpdump в резервной системе:

betaproxyslc01.fakecorp.com> vrrp.mcast.net: vrrp betaproxyslc01.fakecorp.com> vrrp.mcast.net: VRRPv2, Реклама, vrid 51, prio 150, простой тип authtype, intvl 1s, длина 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, intvl 1s, длина 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.

Источник

2 ответа

Решение

Связь 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
[2] http://tools.ietf.org/html/rfc5798

Источник

Обращаясь к информации о брандмауэре в конце этой страницы, я смог заставить ее работать, открыв брандмауэр с помощью:

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.

Источник
Другие вопросы по тегам