web-dev-qa-db-ja.com

VIP keepalivedバックアップからドロップしない

これがどのように機能するのか理解できないかもしれませんが、この基本的なvrrp_instanceを備えたBACKUPシステムがすぐにマスターに移行し、優先順位を尊重していないように見える理由がわかりません。

両方が正常でオンラインの場合、仮想IPアドレスがバックアップシステムから削除されないのはなぜですか？

両方のシステムがvrrp広告をブロードキャストしているようです。バックアップシステムのtcpdumpから：

betaproxyslc01.fakecorp.com> vrrp.mcast.net：vrrp betaproxyslc01.fakecorp.com> vrrp.mcast.net：VRRPv2、広告、 vrid 51、プリオ150、authtype simple、intvl 1s、length 20、> addrs：virtual-app.fakecorp.com auth「パスワード」 15：52：24.541637 IP（tos 0xc0、ttl 255、id 1611、offset 0、flags [none]、proto VRRP（112）、length 40）

betaproxyslc02.fakecorp.com> vrrp.mcast.net：vrrp betaproxyslc02.fakecorp.com> vrrp.mcast.net：VRRPv2、広告、 vrid 51、プリオ100、 authtype simple、intvl 1s、長さ20> addrs：virtual-app.fakecorp.com auth「パスワード」 15：52：25.410073 IP（tos 0xc0、ttl 255、id 1779、offset 0、flags [none]、proto VRRP（112）、length 40）

しかし、仮想IPアドレスは、ip addrコマンドで両方のホストに表示されています。

これが設定です：

global_defs {
   notification_email {
   [email protected]
   }
   notification_email_from [email protected]
   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（2014年6月10日）、Hyper-VゲストVM、3.10.0-123.8.1.el7.x86_64カーネルを使用しています。

linuxkeepalivedload-balance
3
Utegrad

ルーター間の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

5
prupert

このページ の最後にあるファイアウォール情報を参照して、ファイアウォールを次のように開くことで機能させることができました。

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

最初（2つ）のオプションのみが必要であるように思われました。マルチキャストアドレスへのトラフィックを受け入れるようにルールを設定すると、バックアップシステムはvrrpトラフィックに気づき、バックアップモードに戻り、VIPを撤回しました。混乱したのは、tcpdumpを使用して、両方のシステムからの両方のシステムからのマルチキャストトラフィックを確認できたことです。

1
Utegrad