web-dev-qa-db-ja.com

keepalivedが私のSticky VIP構成で2つのMASTERノードを実行しているのはなぜですか？

3ノードのkeepalivedクラスターノードのそれぞれのhaproxyの前にgaleraセットアップ（フローティングVIP）があります。特定のノードでkeepalivedを再起動すると、2つのノードがMASTERで実行されることがあります（/etc/keepalived/log_status.sh通知スクリプト）：

# cat /etc/keepalived/log_status.sh 
#!/bin/bash
echo $1 $2 is in $3 state > /var/run/keepalive.$1.$2.state

私が読んだことから、「複数のマスター」は、スイッチでマルチキャストがフィルター処理されていることが原因ですが、ガレラノードのいずれかでtcpdumpを実行して、MCトラフィックがnicにヒットするのを確認できます（これらはKVM仮想実行中）ユニキャストに変更してみることができますが、これがバグ、機能、または構成によるものかどうかを知りたいです。

# cat /etc/keepalived/keepalived.conf 
log "setting up keepalived"
global_defs {
  router_id    Host1  # short hostname of each KA node (10.20.18.201-203)
}

vrrp_script check_haproxy {
   script      "pidof haproxy"
   interval    2
   weight      2
}

vrrp_instance 250 {
  virtual_router_id 250
  advert_int   1
  nopreempt
  priority     100
  state        BACKUP
  interface    eth0
  notify       /etc/keepalived/log_status.sh

  virtual_ipaddress {
    10.20.18.250 dev   eth0
  }

  track_script {
    check_haproxy
  }
}

tcpdumpの出力：

09:44:00.934942 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:01.936054 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:02.937315 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:03.938444 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:04.942302 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:05.373224 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:05.943936 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:06.029216 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:06.385127 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:06.945303 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:07.333210 IP 10.20.18.201 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:07.946098 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:08.947228 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:09.948507 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:10.548023 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:10.663961 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:10.949633 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:11.559970 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:11.587980 IP 10.20.18.202 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:11.950795 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:12.952124 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:13.953075 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:14.953543 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:15.954703 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:15.987641 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 0, authtype none, intvl 1s, length 20
09:44:15.992698 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:16.008817 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:17.008829 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:17.036879 IP 10.20.18.203 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:44:20.613407 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:21.615616 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:22.616909 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:23.618155 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
09:44:24.619607 IP 10.20.18.203 > 224.0.0.18: VRRPv2, Advertisement, vrid 250, prio 102, authtype none, intvl 1s, length 20
haproxykeepalivedgalera
2
Server Fault

一言で言えば：iptables。

キープアライブの2つのインスタンスを実行していました。1つは内部ネットワークからのアクセスを許可し、もう1つは外部アクセスをサポートします。

内部構成をコピーして、外部のkeepalivedインスタンスを作成しました。 keepalivedが最初のインターフェース（内部インターフェース、eth0）で正しく機能している間、コピーした構成は両方のホストでVIP）を生成していました。

Tcpdumpについての私のレビューでは、bcast VRRPトラフィックがネットワークで許可され、両方のkeepalivedインスタンスから見えることが示されました。内部インターフェイスと外部インターフェイス（eth0 internal/eth1 external）の両方でtcpトラフィックを確認しました。

VRRPトラフィックを許可する必要があります。トラフィックをスニッフィングできることがわかり、正しい（および異なる）優先順位を持つ両方のkeepalivedインスタンスからのVRRPトラフィックを確認しました。ただし、私のiptables構成では、eth1のトラフィックのみが許可されていました。

/ etc/sysconfig/iptabesの関連する行：

以前（eth1のkeepalivedの問題ですが、eth0は問題ありません）：

###Allow multicast for KeepAlived
-A INPUT -i eth0  -d 224.0.0.18/32 -p vrrp -j ACCEPT
-I OUTPUT -o eth0 -d 224.0.0.18/32 -p vrrp -j ACCEPT

後（すべて良い）：

###Allow multicast for KeepAlived
-A INPUT -i eth0  -d 224.0.0.18/32 -p vrrp -j ACCEPT
-I OUTPUT -o eth0 -d 224.0.0.18/32 -p vrrp -j ACCEPT
-A INPUT -i eth1  -d 224.0.0.18/32 -p vrrp -j ACCEPT
-I OUTPUT -o eth1 -d 224.0.0.18/32 -p vrrp -j ACCEPT
2
Mark