ロードバランサの冗長化

投稿者: | 2011年6月19日
0件のコメント
このエントリーをはてなブックマークに追加
Pocket

サーバ環境

製品名 OpenBlockS 600
OS(kernel ver) Debian lenny(2.6.29)
CPU 600MHz(AMCC PowerPC 405EX)
メモリ 1GB(DDR2 SDRAM)
ストレージ 8GB(Compact Flash)

はじめに

前回の記事「keepalived(1.2.1)の導入」ではリアルサーバのサービス監視、および、リアルサーバの障害検知時にロードバランス先からはずす設定の確認を行いました。

今回は、keepalivedでvrrpを動かし、ロードバランサを二重化します。

MASTER/BACKUPが頻繁に切り替わったりダブルMASTERになったりと、非常に不安定な状態が続きましたが、最終的にはうまく動きましたので以下に設定及び確認内容を紹介します。

不安定になった原因については、本記事の末尾に載せています。

冗長化設定

ネットワーク構成について

下図の構成で検証しました。bondingやvlan多重しても動くことを見たいので、若干無理やりですがこのような構成にしています。

VRRPでロードバランサの冗長化

冗長構成試験のため、Openblocks600はOBS-ACTとOBS-SBYの二台を用意しました。また、L2SWについてもc2940-ACTとc2940-SBYの二台を用意しました。

OBS-ACTとc2940-ACT、OBS-SBYとc2940-SBYの間は二本のケーブルで接続し、OBSのeth0,1でbond0を構成しています。また、bond0をクライアント側とリアルサーバ側で論理的に分けるため、bond0.2(赤線：192.168.0.0/24)とbond0.10(青線：172.16.0.0/24)を作成しています。

そのため、OBS～c2940間は4本接続しているように見えますが実際は二本になります。

OBS-ACTとOBS-SBYは、各サブインタフェース(bond0.2、bond0.10)でVRRPを動作させており、MASTER側のOBSがVIPに対するARPに返答を行います。つまり、リアルサーバのARPテーブル上はVIP(172.16.0.3)のMACアドレスがOBS-ACTのMACアドレスになっており、クライアント端末のARPテーブルでもVIP(192.168.0.153)のMACアドレスもOBS-ACTのMACアドレスになっています。

コンフィグ修正

前回の記事「keepalived(1.2.1)の導入」の構成から変更をかけますので、一度keepalivedを止めます。

# svc -d /etc/service/keepalived

本環境ではdaemontoolsを使用しておりますので、上記コマンドで停止させてから修正をかけます。

# vi /usr/local/etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
     abc@example.jp
   }
   notification_email_from user01@example.jp
   smtp_server 11.11.11.11
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}

vrrp_sync_group VG_1 {
    group {
        OUT
        IN
    }
}

vrrp_instance OUT {
    state MASTER
    state BACKUP ※SBY側設定
    interface bond0.2
    virtual_router_id 10
    priority 150
    priority 100 ※SBY側設定
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.0.153/24 dev bond0.2
    }
}

vrrp_instance IN {
    state MASTER
    state BACKUP ※SBY側設定
    interface bond0.10
    virtual_router_id 20
    priority 150
    priority 100 ※SBY側設定
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.16.0.3/24 dev bond0.10
    }
}

virtual_server 192.168.0.153 80 {
    delay_loop 10
    lb_algo rr
    lb_kind NAT
    protocol TCP

    real_server 172.16.0.11 80 {
        weight 1
        inhibit_on_failure
        HTTP_GET {
            url {
              path /index.html
              status_code 200
            }
            connect_timeout 5
            nb_get_retry 10
            delay_before_retry 5
        }
    }

    real_server 172.16.0.12 80 {
        weight 1
        inhibit_on_failure
        HTTP_GET {
            url {
              path /index.html
              status_code 200
            }
            connect_timeout 5
            nb_get_retry 10
            delay_before_retry 5
        }
    }
}

ピンクの箇所がACT/SBYで異なる設定になります。

ロードバランサの外側のIF(bond0.2)または内側のIF(bond0.10)のどちらかがダウンしたら、両側のIFがダウンするようにしています(vrrp_sync_group)。

stateはOBS-ACTをMASTER、OBS-SBYをBACKUPとし、priorityはOBS-ACT＞OBS-SBYとしています。preemptはデフォルトで有効のため、OBS-ACTがダウンしたらOBS-SBYに切り替わり、OBS-ACTがアップしたらOBS-ACTが再度MASTERになる動きをします。

※こちらで紹介されているように、両系BACKUPにしてnopreemptにするとACT/SBY系で同じ設定にできるので、実際の運用ではMASTER/BACKUPはあまり使われていないかもしれません。

real_serverの設定については前回の記事「keepalived(1.2.1)の導入」で取り上げていますので本記事では割愛します。

keepalivedの起動とロードバランス試験

上記設定をOBS-ACT/SBYで行った後、以下のコマンドでkeepalivedを立ち上げます。

# svc -u /etc/service/keepalived

クライアント端末からロードバランスの試験を行います。

C:\Users\user01>curl 192.168.0.153
Hitachi

C:\Users\user01>curl 192.168.0.153
Dell

バランスしました。

動作確認

VRRPについて

以下の右図のようなイメージで動作しています。

サービス監視とVRRPパケット

上図の動きをtcpdumpにて確認します。

OBS-ACT(MASTER)はvrid 10(bond0.2) と 20(bond0.10)、priority 150の224.0.0.18宛VRRPマルチキャストパケットを送出しています。

OBS-SBY(BACKUP)は自分のpriority(100)よりも高いpriorityが聞こえてきているため黙っています。

・OBS-ACT（vlan 2セグメント）

OBS-ACT:~# tcpdump -n -i bond0 vlan 2 and vrrp
tcpdump: WARNING: bond0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes

オプションでvlan指定すると自発パケットは見えないようなので、以下のサブインタフェース指定を利用します。

OBS-ACT:~# tcpdump -n -i bond0.2 vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0.2, link-type EN10MB (Ethernet), capture size 96 bytes
20:44:59.484826 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
20:45:00.488641 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
20:45:01.492644 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
20:45:02.496649 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
20:45:03.500644 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

・OBS-ACT（vlan 10セグメント）

OBS-ACT:~# tcpdump -n -i bond0.10 vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0.10, link-type EN10MB (Ethernet), capture size 96 bytes
20:49:47.632626 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
20:49:48.636493 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
20:49:49.640494 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
20:49:50.644498 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

・OBS-SBY（vlan 2セグメント）

OBS-SBY:~# tcpdump -n -i bond0.2 vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0.2, link-type EN10MB (Ethernet), capture size 96 bytes
20:47:38.158705 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
20:47:39.162734 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
20:47:40.166700 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
20:47:41.170705 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

ACTから聞こえてくるVRRPパケットのpriorityの方が高いため、SBYからはパケット送出していません。

・OBS-SBY（vlan 10セグメント）

OBS-SBY:~# tcpdump -n -i bond0.10 vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0.10, link-type EN10MB (Ethernet), capture size 96 bytes
20:50:31.851342 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
20:50:32.855351 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
20:50:33.859351 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
20:50:34.863356 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

ACTから聞こえてくるVRRPパケットのpriorityの方が高いため、SBYからはパケット送出していません。

ARPについて

数分観察した結果です。

・OBS-ACT

OBS-ACT:~# tcpdump -i bond0.2 not udp and not port 23 and not vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0.2, link-type EN10MB (Ethernet), capture size 96 bytes
      省略
21:01:48.825523 arp who-has 192.168.0.153 tell 192.168.0.7
21:01:48.825641 arp reply 192.168.0.153 is-at 00:0a:85:ff:ff:ff (oui Unknown)
      省略

OBS-ACT(MASTER)は自分のIFアドレスに対するARPに加え、VIP(92.168.0.153)に対するARPにもreplyを返します。

・OBS-SBY

OBS-SBY:~# tcpdump -i bond0.2 not udp and not port 23 and not vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0.2, link-type EN10MB (Ethernet), capture size 96 bytes
      省略
21:01:48.871284 arp who-has 192.168.0.153 tell 192.168.0.7
21:01:53.783297 arp who-has 192.168.0.152 (00:0a:85:ff:ff:20 (oui Unknown)) tell 192.168.0.7
21:01:53.783374 arp reply 192.168.0.152 is-at 00:0a:85:ff:ff:20 (oui Unknown)
      省略

OBS-SBY(BACKUP)はVIPに対するARPには黙っています。

障害試験

OBS-ACTのbond0.10を落とします。

投入時刻は21:31:30です。

OBS-ACT:~# ip link set bond0.10 down

VRRPパケットの様子

・OBS-ACT

OBS-ACT:~#  tcpdump -i bond0 vrrp

21:31:28.120671 IP 192.168.0.151 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
21:31:29.124498 IP 172.16.0.1 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
21:31:29.124668 IP 192.168.0.151 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
21:31:30.128496 IP 172.16.0.1 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
21:31:30.128664 IP 192.168.0.151 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
^C
156 packets captured
158 packets received by filter
0 packets dropped by kernel

bond0.10を閉塞した21:31:30を最後に、vrrpの送出がbond0.2、bond0.10の両系で止まりました(vrrp_sync_groupの効果が確認できました)。

・OBS-SBY（vlan 2セグメント）

OBS-SBY:~# tcpdump -n -i bond0.2 vrrp

21:31:29.178366 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
21:31:30.182367 IP 192.168.0.151 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 150, authtype simple, intvl 1s, length 20
21:31:33.796244 IP 192.168.0.152 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 100, authtype simple, intvl 1s, length 20
21:31:33.803532 IP 192.168.0.152 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 100, authtype simple, intvl 1s, length 20
21:31:34.806988 IP 192.168.0.152 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 100, authtype simple, intvl 1s, length 20
21:31:35.811756 IP 192.168.0.152 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 100, authtype simple, intvl 1s, length 20

OBS-ACTのbond0.10がダウンしてから3秒後(OBS-ACTからVRRPパケットが1秒 x 3回来なかったのを契機に)にOBS-SBYのbond0.2からvrrpの送出が開始されています。

・OBS-SBY（vlan 10セグメント）

OBS-SBY:~# tcpdump -n -i bond0.10 vrrp

21:31:29.178197 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
21:31:30.182199 IP 172.16.0.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 150, authtype simple, intvl 1s, length 20
21:31:33.794963 IP 172.16.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 100, authtype simple, intvl 1s, length 20
21:31:34.804184 IP 172.16.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 100, authtype simple, intvl 1s, length 20
21:31:35.810995 IP 172.16.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 20, prio 100, authtype simple, intvl 1s, length 20

同じくOBS-ACTのbond0.10がダウンしてから4秒後(OBS-ACTからVRRPパケットが1秒 x 3回来なかったのを契機に)にOBS-SBYのbond0.10からvrrpの送出が開始されています。

ARPパケットの様子

・OBS-ACT（vlan 2セグメント）

OBS-ACT:~# tcpdump -i bond0 arp

21:31:23.764395 arp who-has 192.168.0.1 tell 192.168.0.151
21:31:43.193401 arp reply 192.168.0.151 is-at 00:0a:85:ff:ff:ff (oui Unknown)
21:32:25.988044 arp reply 192.168.0.151 is-at 00:0a:85:ff:ff:ff (oui Unknown)
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

自IFへのARPに対してしか反応していません。

・OBS-SBY（vlan 2セグメント）

OBS-SBY:~# tcpdump -i bond0 arp
tcpdump: WARNING: bond0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 96 bytes
21:31:33.800147 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:33.802972 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:33.803119 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:33.803254 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:33.803386 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:34.803458 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:34.803625 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:34.803758 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:34.803891 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:34.804023 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:38.806837 arp who-has 192.168.0.1 tell 192.168.0.152
21:31:38.811177 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:38.811342 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:38.811474 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:38.811606 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:38.811739 arp who-has 192.168.0.153 (Broadcast) tell 192.168.0.153
21:31:39.753756 arp reply 192.168.0.152 is-at 00:0a:85:ff:ff:20 (oui Unknown)
21:31:39.810932 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:39.811112 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:39.811245 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:39.811377 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:39.811510 arp who-has 172.16.0.3 (Broadcast) tell 172.16.0.3
21:31:43.246852 arp who-has 192.168.0.151 tell 192.168.0.152
21:32:03.219260 arp reply 192.168.0.153 is-at 00:0a:85:ff:ff:20 (oui Unknown)
21:32:03.515995 arp reply 192.168.0.153 is-at 00:0a:85:ff:ff:20 (oui Unknown)
21:32:11.753022 arp reply 192.168.0.152 is-at 00:0a:85:ff:ff:20 (oui Unknown)
21:32:23.882811 arp who-has 192.168.0.1 tell 192.168.0.152
^C
27 packets captured
27 packets received by filter
0 packets dropped by kernel

OBS-ACTのbond0.10がダウンしてから3秒後(21:31:33)にGARPを送出し、その5秒後(21:31:38)に再度GARPを送出してL2SWのMACテーブルの書き換えを行っています。

5秒遅れで送出しているのはkeepalived.confのgarp_master_delay設定を行っていないため、defaultの5秒がきいているからです。

ARPテーブル

・リアルサーバ1(dell)

dell:~# ip neigh show
172.16.0.1 dev eth0.10 lladdr 00:0a:85:ff:ff:ff REACHABLE
172.16.0.2 dev eth0.10 lladdr 00:0a:85:ff:ff:20 REACHABLE
172.16.0.3 dev eth0.10 lladdr 00:0a:85:ff:ff:20 REACHABLE

VIPのMACがOBS-SBYに変更されました。

・リアルサーバ2(Hitachi)

hitachi:~# ip neigh show
172.16.0.2 dev eth0.10 lladdr 00:0a:85:ff:ff:20 REACHABLE
172.16.0.1 dev eth0.10 lladdr 00:0a:85:ff:ff:ff REACHABLE
172.16.0.3 dev eth0.10 lladdr 00:0a:85:ff:ff:20 REACHABLE

VIPのMACがOBS-SBYに変更されました。

クライアント端末

C:\Users\user01>arp -a

インターフェイス: 192.168.0.7 --- 0xa
  インターネット アドレス      物理アドレス      種類
  192.168.0.151        00-0a-85-ff-ff-ff     動的
  192.168.0.152        00-0a-85-ff-ff-20     動的
  192.168.0.153        00-0a-85-ff-ff-ff     動的

VIPのMACがOBS-SBYに変更されました。

ロードバランス試験

C:\Users\user01>curl 192.168.0.153
Hitachi

C:\Users\user01>curl 192.168.0.153
Dell

OBS-SBY経由で正常動作しています。

VRRPが不安定になった原因

VRRPを最初に試した時、ロードバランス動作がうまくいったりいかなかったりというのが継続して発生していました。

サーバにてip neigh showを確認すると、VIPのMACが頻繁に切り替わっていました(ロードバランサのMASTER/BACKUPが頻繁に切り替わっているのが原因でした。)

まず疑ったのはkeepalived.confの設定です。keepalived.confのシンタックスチェックツールなるものを発見し早速試してみましたが…

OBS-ACT:~# keepalived-check /usr/local/etc/keepalived/keepalived.conf
ok

OBS-SBY:~# keepalived-check /usr/local/etc/keepalived/keepalived.conf
ok
OBS-SBY:~#

残念ながら(?)、特に問題無しでした。

bonding or vlan と相性が悪い？O’REILLYのサイトにはsub-ifはいけそうなことが書いてありますし、よかろうもん！さんのサイトのようにbondインタフェース使っている方もいるので、別問題な気がしますが…試しにeth0とeth1の構成にしてみましたが、やはり不安定なままでした。

その後、1.2.1特有のバグかもしれないと思い、1.2.0に落としてみても事象は変わりませんでした。

tcpdumpをしてみると、OBS-ACT/SBYともにVRRPを送出しており、SBY側がACTからのVRRPパケットを受け取れているにもかかわらず無視しているように見えました。

ログを見てみると以下のようになっていました。

OBS-ACT:~# tail -100 /var/log/messages

Jun 14 23:37:31 OBS-ACT Keepalived_vrrp: VRRP_Instance(Inside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:32 OBS-ACT Keepalived_vrrp: VRRP_Instance(Outside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:32 OBS-ACT Keepalived_vrrp: VRRP_Instance(Inside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:33 OBS-ACT Keepalived_vrrp: VRRP_Instance(Outside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:33 OBS-ACT Keepalived_vrrp: VRRP_Instance(Inside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:34 OBS-ACT Keepalived_vrrp: VRRP_Instance(Outside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:34 OBS-ACT Keepalived_vrrp: VRRP_Instance(Inside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:35 OBS-ACT Keepalived_vrrp: VRRP_Instance(Outside-IF) Received lower prio advert, forcing new election
Jun 14 23:37:35 OBS-ACT Keepalived_vrrp: VRRP_Instance(Inside-IF) Received lower prio advert, forcing new election

OBS-SBY:~# tail -100 /var/log/messages

Jun 14 23:30:23 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Transition to MASTER STATE
Jun 14 23:30:23 www Keepalived_vrrp: VRRP_Group(VG_1) Syncing instances to MASTER state
Jun 14 23:30:23 www Keepalived_vrrp: VRRP_Instance(Inside-IF) Transition to MASTER STATE
Jun 14 23:30:23 www Keepalived_vrrp: VRRP_Instance(Inside-IF) Entering MASTER STATE
Jun 14 23:30:24 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Entering MASTER STATE
Jun 14 23:41:50 www kernel: device bond0 entered promiscuous mode
Jun 14 23:41:50 www kernel: device eth0 entered promiscuous mode
Jun 14 23:41:51 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Received higher prio advert
Jun 14 23:41:51 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Entering BACKUP STATE
Jun 14 23:41:51 www Keepalived_vrrp: VRRP_Group(VG_1) Syncing instances to BACKUP state
Jun 14 23:41:51 www Keepalived_vrrp: VRRP_Instance(Inside-IF) Entering BACKUP STATE
Jun 14 23:41:55 www kernel: device bond0 left promiscuous mode
Jun 14 23:41:55 www kernel: device eth0 left promiscuous mode
Jun 14 23:41:59 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Transition to MASTER STATE
Jun 14 23:41:59 www Keepalived_vrrp: VRRP_Group(VG_1) Syncing instances to MASTER state
Jun 14 23:41:59 www Keepalived_vrrp: VRRP_Instance(Inside-IF) Transition to MASTER STATE
Jun 14 23:41:59 www Keepalived_vrrp: VRRP_Instance(Inside-IF) Entering MASTER STATE
Jun 14 23:42:00 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Entering MASTER STATE
Jun 14 23:42:00 www kernel: device bond0 entered promiscuous mode
Jun 14 23:42:01 www kernel: device eth0 entered promiscuous mode
Jun 14 23:42:01 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Received higher prio advert
Jun 14 23:42:01 www Keepalived_vrrp: VRRP_Instance(Outside-IF) Entering BACKUP STATE
Jun 14 23:42:01 www Keepalived_vrrp: VRRP_Group(VG_1) Syncing instances to BACKUP state
Jun 14 23:42:01 www Keepalived_vrrp: VRRP_Instance(Inside-IF) Entering BACKUP STATE
Jun 14 23:42:05 www kernel: device bond0 left promiscuous mode
Jun 14 23:42:05 www kernel: device eth0 left promiscuous mode

不定期な間隔でReceived higher prio advertで気付きBACKUPに戻るのですが、またMASTERになるというのを繰り返しています。マルチキャスト(2)にも類似事象が書かれていましたが少し様子が異なるようです。

試行錯誤し尽くしてあきらめかけたところでふと気付いたのですが、tcpdumpを実行するタイミングでIFがpromiscuous modeになり(entered promiscuous mode)、SBY側がBACKUPに推移していることに気付きました。そして、tcpdumpを止めるとpromiscuous modeが終わり(left promiscuous mode)、なぜかMASTERに戻ってしまう。本来keepalivedでVRRPを動かすとpromiscuous modeに推移するはずなのかもしれません。であれば、bond0をpromiscuous modeにしてしまえば正常動作しそうです。

OBS-ACT:~# ip addr show
   省略
4: bond0:  mtu 1500 qdisc noqueue state UP
    link/ether 00:0a:85:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20a:85ff:fe04:2ff/64 scope link
       valid_lft forever preferred_lft forever

OBS-ACT:~# ifconfig bond0 -promisc

OBS-ACT:~# ip addr show
   省略
4: bond0: PROMISC,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:0a:85:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20a:85ff:fe04:2ff/64 scope link
       valid_lft forever preferred_lft forever

OBS-ACT/SBYの両系をpromiscuous modeにして再度/var/log/messagesを確認したところ、正常動作になりました。

リロードしても反映されるように設定します。

OBS-ACT:~# vi /etc/network/interfaces

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
up /sbin/ifconfig bond0 0.0.0.0 up
up /sbin/ifconfig bond0 promisc on
slaves eth0 eth1

web上で類似の情報が全く無いので推測ですが、通常keepalivedでVRRPを動作させると自動的にpromiscuous modeに推移するのでしょうか？であれば、なぜ動かなかったのか？今度、時間ができた時にじっくりネットワークプログラミングの勉強をしてからソース読んで考えてみようと思います。

参考文献

こんなに簡単！ Linuxでロードバランサ (1)

keepalivedの運用ノウハウお見せします ～ 設定ファイルを同期する

よかろうもん！さんのサイト

More from my site

このエントリーをはてなブックマークに追加
Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です