keepalivedでフェイルバック無効(nopreempt)にしたときの挙動

keepalivedについて以前にいくつかのエントリでご紹介しました。

• keepalivedを利用する際に気をつけておくこと
• bondingとkeepalivedを組み合わせる

これら2つのエントリで紹介したkeepalivedの技術を組み合わせた構成で、各サーバでのkeepalivedのstatusをBACKUPにし、フェイルバック無効(nopreempt)にしたときの挙動について調査しました。
なぜ調査をしたかといいますと、keepalivedのフェイルバックの動作で疑問に感じることがあったためです。

今回のシステム構成は以下の図のように、eth0とeth2でbonding(Active-Backup)を組んでおき、さらにbond0に2つの仮想IPアドレスを、eth1に1つの仮想IPアドレスを割り当てます。

keepalivedの設定はこちらの設定内容とほぼ同じで、vrrp_instance SERVICEのinterfaceがbond0に変更となるだけです。

それでは、初期状態ではserver1のbond0およびeth1に仮想IPが割り振られていると仮定して、以下のような条件でのkeepalivedの振る舞いを確認してみます。

• 仮想IPが割り当てられているserver1がダウン(keepalivedを停止)
• 仮想IPが割り当てられているserver1のインタフェースが停止

検証をする前に1点だけおさらいをしておきます。
server1およびserver2のkeepalivedの設定が、以下のような条件の場合は、keepalivedを先に起動した側が常にMASTERとなることが約束されています。

• statusがBACKUP
• 各インスタンスのpriorityが同一
• nopreempt

うざいようですが、keepalivedを先に起動した側が常にMASTERとなります。
keepalivedを先に起動した側が常にMASTERとなります。
keepalivedを先に起動した側が常にMASTERとなります。。。

それでは検証をしていきます。

server1がダウン(keepalivedを停止)

サーバがダウンしたという想定のもとkeepalivedを停止します。

[server1]$ sudo /etc/init.d/keepalived stop

続いて、数秒待ってからserver2で以下のコマンドを発行し、仮想IPアドレスが割り当てられていることを確認します。

[server2]$ /sbin/ip addr
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: bond0: mtu 1500 qdisc noqueue
link/ether 00:21:5a:ac:78:da brd ff:ff:ff:ff:ff:ff
inet 192.168.2.11/24 brd 192.168.2.254 scope global bond0
inet 192.168.2.1/24 scope global secondary bond0
inet 192.168.2.2/24 scope global secondary bond0
3: eth0: mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.1.2.11/24 brd 10.1.2.254 scope global eth1
inet 10.1.2.1/24 scope global secondary eth1
5: eth2: mtu 1500 qdisc pfifo_fast master bond0 qlen 100
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

server1が復旧したと仮定し、keepalivedを起動します。

[server1]$ sudo /etc/init.d/keepalived start

数秒待機してから再度server2で仮想IPアドレスが割り振られているかどうかを確認します。
すると仮想IPアドレスはserver2に割り当てられたままとなっており、フェイルバックが無効になっていることが確認できます。

[server2]$ /sbin/ip addr
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: bond0: mtu 1500 qdisc noqueue
link/ether 00:21:5a:ac:78:da brd ff:ff:ff:ff:ff:ff
inet 192.168.2.11/24 brd 192.168.2.254 scope global bond0
inet 192.168.2.1/24 scope global secondary bond0
inet 192.168.2.2/24 scope global secondary bond0
3: eth0: mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.1.2.11/24 brd 10.1.2.254 scope global eth1
inet 10.1.2.1/24 scope global secondary eth1
5: eth2: mtu 1500 qdisc pfifo_fast master bond0 qlen 100
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

念のためにserver2で取得したログも確認しておきます。

[server2]$ sudo view /var/log/message

Oct 23 22:38:10 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Transition to MASTER STATE
Oct 23 22:38:10 server2 Keepalived_vrrp: VRRP_Group(VG) Syncing instances to MASTER state
Oct 23 22:38:10 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Transition to MASTER STATE
Oct 23 22:38:10 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Entering MASTER STATE
Oct 23 22:38:10 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) setting protocol VIPs.
Oct 23 22:38:10 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Sending gratuitous ARPs on eth1 for 10.1.2.1
Oct 23 22:38:13 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Entering MASTER STATE
Oct 23 22:38:13 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) setting protocol VIPs.
Oct 23 22:38:13 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.1
Oct 23 22:38:13 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.2
Oct 23 22:38:15 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Sending gratuitous ARPs on eth1 for 10.1.2.1
Oct 23 22:38:18 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.1
Oct 23 22:38:18 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.2

もともとserver2に仮想IPアドレスは割り当てられておらず、BACKUPで動作していましたが、server1のkeepalivedを停止してserver2がMASTERになっています。
server2がMASTERになってからGARPを送出してからはserver1が復旧してもステータスは変わっていません。

server1のbond0インタフェースをダウンさせて、数秒後にbond0を復旧させた場合

それでは仮想IPアドレスが割り当てられているserver1のbond0インタフェースをダウンさせます。
ダウンさせた時刻は22:17:26です。

[server1]$ sudo /sbin/ifdown bond0

仮想IPアドレスがserver2に引き継がれたことを確認して、bond0インタフェースをアップさせます。
アップさせた時刻は22:18:08です。

その時のserver2でのtcpdumpの結果は以下の通りです。

[server2]$ sudo /usr/sbin/tcpdump -i bond0 -n vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes
22:17:20.122825 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:23.123700 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:26.124602 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:29.126464 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:38.736333 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:41.738310 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:44.739085 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:47.739966 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:50.740848 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:53.741736 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:56.742617 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:17:59.743500 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:18:02.744383 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:18:05.745267 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:18:08.747166 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:18:10.566840 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:18:13.567906 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:18:16.568602 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:18:19.570474 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24

上記のオペレーションの結果、server1からserver2にフェイルオーバし、server1のbond0が復旧するとフェイルバックしています。

さらにこのときのserver2のログを念のために確認しておきます。

[server2]$ view /var/log/message
Oct 23 22:17:38 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Transition to MASTER STATE
Oct 23 22:17:38 server2 Keepalived_vrrp: VRRP_Group(VG) Syncing instances to MASTER state
Oct 23 22:17:38 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Transition to MASTER STATE
Oct 23 22:17:39 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Entering MASTER STATE
Oct 23 22:17:39 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) setting protocol VIPs.
Oct 23 22:17:39 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Sending gratuitous ARPs on eth1 for 10.1.2.1
Oct 23 22:17:41 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Entering MASTER STATE
Oct 23 22:17:41 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) setting protocol VIPs.
Oct 23 22:17:41 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.1
Oct 23 22:17:41 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.2
Oct 23 22:17:44 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Sending gratuitous ARPs on eth1 for 10.1.2.1
Oct 23 22:17:46 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.1
Oct 23 22:17:46 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.2
Oct 23 22:18:10 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Received higher prio advert
Oct 23 22:18:10 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Entering BACKUP STATE
Oct 23 22:18:10 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) removing protocol VIPs.
Oct 23 22:18:10 server2 Keepalived_vrrp: VRRP_Group(VG) Syncing instances to BACKUP state
Oct 23 22:18:10 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Entering BACKUP STATE
Oct 23 22:18:10 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) removing protocol VIPs.
Oct 23 22:18:20 server2 kernel: device eth0 left promiscuous mode
Oct 23 22:18:20 server2 kernel: device bond0 left promiscuous mode

※最後のpromiscuos modeの出力については、tcpdumpを利用したためです。

このログでおかしな点が1つあります。
それはserver2のtcpdumpの結果では、server1およびserver2が送出しているpriorityは互いに100なのに、server2がReceived higher prio advertと判断し、MASTERからBACKUPに遷移しています。

上記の結果より、keepalivedがダウンすることなくインタフェースがダウンして状態が変化した場合は、インタフェースが復旧するとフェイルバックすることがわかりました。

server1のbond0,eth1インタフェースを順にダウンさせて、数秒後にbond0,eth1を順に復旧させた場合

server1でのオペレーションは以下の通りです。

[server1]$ sudo /sbin/ifdown bond0　＃22:25:34ごろ
[server1]$ sudo /sbin/ifdown eth1　 ＃22:25:59ごろ
[server1]$ sudo /sbin/ifup bond0　＃22:26:20ごろ
[server1]$ sudo /sbin/ifup eth1　 ＃22:26:38ごろ

その時のserver2でのtcpdumpの結果は以下の通りです。

[server2]$ sudo /usr/sbin/tcpdump -i bond0 -n vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes
22:25:31.700178 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:25:34.701045 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:25:44.311161 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:25:47.312136 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:25:50.312908 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:25:53.313783 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:25:56.314660 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:25:59.315536 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:02.316413 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:05.317290 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:08.318166 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:11.319045 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:14.319921 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:17.320798 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:20.321676 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:23.322552 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:26.323428 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:29.324306 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:32.325181 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:35.326060 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:38.326935 IP 192.168.2.11 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:38.332457 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:47.937151 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:50.937875 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:53.939751 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:56.940623 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:26:59.941500 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:27:02.942375 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:27:05.943249 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:27:08.944125 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:27:11.945000 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:27:14.945876 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24
22:27:17.946749 IP 192.168.2.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 3s, length 24

また、server2のログは以下の通りです。

[server2]$ view /var/log/message
Oct 23 22:25:44 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Transition to MASTER STATE
Oct 23 22:25:44 server2 Keepalived_vrrp: VRRP_Group(VG) Syncing instances to MASTER state
Oct 23 22:25:44 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Transition to MASTER STATE
Oct 23 22:25:47 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Entering MASTER STATE
Octy 23 22:25:47 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) setting protocol VIPs.
Oct 23 22:25:47 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Sending gratuitous ARPs on eth1 for 10.1.2.1
Oct 23 22:25:47 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Entering MASTER STATE
Oct 23 22:25:47 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) setting protocol VIPs.
Oct 23 22:25:47 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.1
Oct 23 22:25:47 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.2
Oct 23 22:25:52 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Sending gratuitous ARPs on eth1 for 10.1.2.1
Oct 23 22:25:52 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.1
Oct 23 22:25:52 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Sending gratuitous ARPs on bond0 for 192.168.226.2
Oct 23 22:26:38 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Received higher prio advert
Oct 23 22:26:38 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) Entering BACKUP STATE
Oct 23 22:26:38 server2 Keepalived_vrrp: VRRP_Instance(BACKEND) removing protocol VIPs.
Oct 23 22:26:38 server2 Keepalived_vrrp: VRRP_Group(VG) Syncing instances to BACKUP state
Oct 23 22:26:38 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) Entering BACKUP STATE
Oct 23 22:26:38 server2 Keepalived_vrrp: VRRP_Instance(SERVICE) removing protocol VIPs.
Oct 23 22:27:18 server2 kernel: device eth0 left promiscuous mode
Oct 23 22:27:18 server2 kernel: device bond0 left promiscuous mode

以上より、server1のbond0インタフェースをダウンさせて、数秒後にbond0を復旧させた場合と同じ結果となっていることが確認できました。

結論

今回の検証より以下のことが確認できました。

• keepalivedのサービスを停止してから、サービスを起動しなおしてもフェイルバックしない
• keepalivedでは意図的にインタフェースをダウンさせた場合は、フェイルバックする

ただし、今回検証したのは特定のインタフェースのみをダウンするやり方であり、サーバの全てのインタフェースをダウン(/etc/init.d/network stop)した結果ではありません。
また、インタフェースをダウンさせるのではなく、LANケーブルを抜いた場合にどのような振る舞いになるかについても考慮されていません。
今回の結果より、keepalivedを先に起動した側が常にMASTERとなることが確認できましたので、おそらくサーバ全てのネットワークをダウンしたり、LANケーブルを抜き差ししてもフェイルバックするのではないかと考えられます。

参考サイト

• http://osdir.com/ml/linux.keepalived.devel/2006-09/msg00004.html