DSAS開発者の部屋

まずは構成図からいきます。

                    ┌─────┐

                    │  client  │

                    └──┬──┘

                          │[10.10.31.200]

                          │

  ━━━━━━━┯━━━━┷━━━━━┯━━━━━━━━━ 10.10.31.0/24

                │                    │

                │                    │

                │ ←(10.10.31.10) → │

                │ ←{10.10.31.100}→ │

   [10.10.31.11]│                    │[10.10.31.12]

            ┌─┴─┐            ┌─┴─┐

            │ lv1  │            │ lv2  │

            └─┬─┘            └─┬─┘

 [192.168.31.11]│                    │[192.168.31.12]

                │ ←(192.168.31.10)→│

                │                    │

  ━━━━━━┯┷━━━━━━━━━━┷┯━━━━━━━━ 192.168.31.0/24

              │                        │

              │[192.168.31.101]        │[192.168.31.102]

          ┌─┴─┐                ┌─┴─┐

          │ w101 │                │ w102 │

          └───┘                └───┘

10.10.31.0/24

説明上、このアドレス帯をグローバルアドレスとして使います。

• 10.10.31.10 : VRRPの仮想IPアドレスです（今回の目玉）
  
• 10.10.31.11 : lv1の外側(eth0)のIPアドレスです
  
• 10.10.31.12 : lv2の外側(eth0)のIPアドレスです
  
• 10.10.31.100: Webサービス用の仮想IPアドレスです(http://example.org/)
  
• 10.10.31.200: 通信確認をするためのクライアントマシンのIPアドレスです
  

　

192.168.31.0/24

構内のネットワーク用のアドレス帯です。

• 192.168.31.10 : VRRPの仮想IPアドレスです（今回の目玉）
  
• 192.168.31.11 : lv1の内側（eth1）のIPアドレスです
  
• 192.168.31.12 : lv2の内側（eth1）のIPアドレスです
  
• 192.168.31.101: リアルサーバw101のIPアドレス(RIP)です
  
• 192.168.31.102: リアルサーバw102のIPアドレス(RIP)です
  

前回までの構成と大きく異なる点は、lv2 というマシンが増えているところです。
lv2 は IPアドレスとホスト名以外は lv1 と全く同じ構成のマシンとします。
今回は lv1 がダウンしても lv2 が機能を引き継ぐような冗長構成を組んでみます。

※lv1 と lv2 には 10.10.31.10 と 192.168.31.10 を割り当てないでおいて下さい。
（このアドレスは keepalived が自動的に割り当てます）

VRRPを使う前に

以降の作業では、基本的に lv1,w101,w102 が前回までの通りに構成されている事を前提としますが、若干の変更点がありますので以下の通りに設定変更をしてください。

• w101,w102 のデフォルトゲートウエイを 192.168.31.10 にする
  
• clientは 10.10.31.100 宛のパケットを 10.10.31.10 へルーティングする
  

実際の環境では、lv1,lv2の上位にISPのルータが繋がってルーティングしてくれると思いますが、今回は便宜上 client のルーティングテーブルを直接操作して経路を繋ぐようにします。つまり、clientが 10.10.31.100 へ到達するためには 10.10.31.10 というルータが必要となるような構成にします。

clientがLinuxの場合はコンソールから

# route add -host 10.10.31.100 gw 10.10.31.10

clientがWindowsの場合はコマンドプロンプトから

C:\>route add 10.10.31.100 mask 255.255.255.255 10.10.31.10

を実行してください。
これによって、clientからの 10.10.31.100(example.org) 宛のパケットは 10.10.31.10(VIP) に転送されるようになります。

VRRPを設定しよう

大変お待たせしました。
それでは前回作った keepalived.conf に VRRPの設定を追加してみましょう。

まずは lv1 の /usr/klab/etc/keepalived.conf に以下の内容を追加します。

vrrp_instance VI {

  state BACKUP

  interface eth1

  garp_master_delay 5

  virtual_router_id 1

  priority 101

  nopreempt

  advert_int 1

  authentication {

    auth_type PASS

    auth_pass himitsu

  }

  virtual_ipaddress {

    10.10.31.10/24   dev eth0

    192.168.31.10/22 dev eth1

  }

}

同様に lv2 の /usr/klab/etc/keepalived.conf に以下の内容を追加します。

vrrp_instance VI {

  state BACKUP

  interface eth1

  garp_master_delay 5

  virtual_router_id 1

  priority 100

  nopreempt

  advert_int 1

  authentication {

    auth_type PASS

    auth_pass himitsu

  }

  virtual_ipaddress {

    10.10.31.10/24   dev eth0

    192.168.31.10/22 dev eth1

  }

}

値が異なるのは priority だけです。その他の項目は同じにします。
スルドイ方は「なぜに lv1 も lv2 も state BACKUP なの？」と疑問に感じるかもしれませんが、今回はとりあえずこのままの設定で動かしてしまいます。

VRRPを動かしてみよう

keepalived の VRRP機能を使うには、起動オプションに --vrrp を指定します。

まずは lv1 で 以下のコマンドを実行します。
（すでに keepalived が動いている場合は停止させておいて下さい）

lv1# /usr/klab/sbin/keepalived -n -S 1 -d -f /usr/klab/etc/keepalived.conf \

     --check --vrrp

すると lv1 のsyslogに以下のようなメッセージが流れます。

lv1 Keepalived: Starting Keepalived v1.1.12 (08/22,2006)

lv1 Keepalived: Starting Healthcheck child process, pid=3554

lv1 Keepalived_vrrp: Using LinkWatch kernel netlink reflector...

lv1 Keepalived_vrrp: Registering Kernel netlink reflector

lv1 Keepalived_vrrp: Registering Kernel netlink command channel

lv1 Keepalived_vrrp: Registering gratutious ARP shared channel

lv1 Keepalived: Starting VRRP child process, pid=3555



・・・（中略）・・・



lv1 Keepalived_vrrp: VRRP_Instance(VI) Entering BACKUP STATE

lv1 Keepalived_vrrp: VRRP_Instance(VI) Transition to MASTER STATE

lv1 Keepalived_vrrp: VRRP_Instance(VI) Entering MASTER STATE

keepalivedが起動し、VRRPのMASTERとなったことがわかると思います。
次に ip コマンドを使って仮想IPアドレスが振られているかどうかを確認します。
(ifconfigコマンドでは確認できないのでご注意下さい)

root@lv1:~# ip addr show eth0

    inet 10.10.31.11/16 brd 10.10.255.255 scope global eth0

    inet 10.10.31.100/32 scope global eth0:100

    inet 10.10.31.10/24 scope global eth0



root@lv1:~# ip addr show eth1

    inet 192.168.31.11/16 brd 192.168.31.255 scope global eth1

    inet 192.168.31.10/22 scope global eth1

ちゃんと VRRP の仮想IPが振られているようです。
これで client から 10.10.31.100 に通信できるようになったはずです。

client:~$ curl -H 'Host: example.org' http://10.10.31.100

w101 nano

client:~$ curl -H 'Host: example.org' http://10.10.31.100

w102 desu

同様に lv2 でも keepalived を起動します。

lv2# /usr/klab/sbin/keepalived -n -S 1 -d -f /usr/klab/etc/keepalived.conf \

     --check --vrrp

すると lv2 のsyslogには以下のようなメッセージが流れます。

lv2 Keepalived_vrrp: VRRP_Instance(VI) Entering BACKUP STATE

lv1 が Master として動いているため、lv2 は MASTER STATE にはならず、BACKUP STATE のままで待機していることがわかります。従って、仮想IPは割り当てられません。

root@lv2:~# ip addr show eth0

    inet 10.10.31.12/16 brd 10.10.255.255 scope global eth0

    inet 10.10.31.100/32 scope global eth0:100



root@lv2:~# ip addr show eth1

    inet 192.168.31.12/16 brd 192.168.31.255 scope global eth1

VRRPの動作を体感しよう

さて、ここからがメインイベントです。
ここまでで lv1=Master lv2=Backup としてVRRPが稼働し、 client から http://example.org/ を閲覧できる状態になっていることと思います。

ここで思い切って lv1 をシャットダウンしてみましょう。

・・・とそのまえに、clientで ping でも投げておきましょうか。

client:$ ping 10.10.31.10



(Windwos の場合は -t を付けてください)

lv1:# shutdown -h now

lv1を止めても ping が途切れない事がわかると思います。

client:~$ curl -H 'Host: example.org' http://10.10.31.100

w102 desu

client:~$ curl -H 'Host: example.org' http://10.10.31.100

w101 nano

HTTPアクセスも正常なようです。
そこで lv2 の IPアドレスを確認してみると

root@lv2:~# ip addr show eth0

    inet 10.10.31.12/16 brd 10.10.255.255 scope global eth0

    inet 10.10.31.100/32 scope global eth0:100

    inet 10.10.31.10/24 scope global eth0



root@lv2:~# ip addr show eth1

    inet 192.168.31.12/16 brd 192.168.31.255 scope global eth1

    inet 192.168.31.10/22 scope global eth1

となっており、さっきまで lv1 に振られていたVIP(10.10.31.10 と 192.168.31.10)が自動的に lv2 に切り替わっていることが確認できます。

これで、lv1 と lv2 のどちらかの keepalived が動いてさえいればサービスが止まる事はないはずです。これでなんとなく枕を少しだけ高くして寝ることができそうな気がしませんか？

keepalivedのVRRP機能は結構使い勝手がよく、とりまわしが楽なので工夫次第で様々な用途に使えると思います。たとえば、Webサーバ1台で処理できるような負荷分散不要なサイトであれば、WEBサーバを2台にして、それぞれで keepalived を動かすだけで冗長構成にすることもできると思います。

ただ、やはり大量のアクセスを処理したいというニーズが多いのも事実なので、次回はこれらの機材を使ってDSR構成を試してみたいと思います。