2006年08月30日

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

はてなブックマークに登録

前回はkeepalivedを使ってWebサーバを冗長化してみました。
今回はkeepalivedのもう一つの機能であるVRRPを使って、ロードバランサ自身を冗長構成にしてみたいと思います。


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

┌─────┐
│ 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構成を試してみたいと思います。


klab_gijutsu2 at 13:07│Comments(7)TrackBack(1)lvs | 冗長構成

トラックバックURL

この記事へのトラックバック

1. LVS+keepalived  [ おれぶろぐ ]   2006年09月06日 23:19
LVSとkeepalivedを使ったPCによる負荷分散構成の話。 ただ、keepalivedのVRRPによるネットワーク的な冗長構成に関してちょっと気になる、というか疑問点あり。

この記事へのコメント

1. Posted by _goma   2006年09月01日 10:09
5 IPnutsでこの辺の設定が、Webインターフェースで設定できます。(Free版はダメ)
マニュアルです。
http://s-me.co.jp/ipnuts/ipnuts4r3/html/IPnuts4_LVS/
2. Posted by Yasui   2006年09月01日 22:14
IPnutsもいつの間にかかなり高機能になりましたよね。価格もお手ごろなので開発用のロードバランサとしてのニーズは結構あるんじゃないですか?

ああ、FD一枚でマスカレードできるルータがある事に感動していた時代が懐かしいです(笑
3. Posted by SNE   2006年09月06日 23:22
わざわざコメントありがとうございました(^^)
最初からTBうってたんですが、失敗してまして、概要手入力したらやっとTB送信成功しました…。
4. Posted by Yasui   2006年09月07日 14:25
あ、そうでしたか。

なにせ実環境では vrrp_sync_group 使ってなかったもので、私もすっかりその存在を忘れ去っていました(^^;;

別な機会にでも、もう少し実環境で使えそうな例を上げてみたいと思います。
5. Posted by Fujii   2007年11月25日 11:26
すごく参考にさせていただいております。我が家にてPCを5台動かしながらVRRPを勉強中です。暖房器具代わりです。
確かに lvs_sync_daemon_interface eth1
を記述することでコネクションをフェールオーバーできることを確認しました。しかし、、、しばらくはActiveConnに残っているようです。スケジューリングポリシーにwlcを採用している場合には、残っていない側にジョブが集中してしまいます。
忘れたころ?に消えましたが。。。
あ、ちょっと混乱してきました。
どうあるべきなのかも自信なくなりました。

6. Posted by Mars07   2009年05月13日 04:26
大変参考にさせていただいております。貴重な情報をありがとうございます。

質問になりますが、VRRPのVIPとWeb Service VIPを同じIPにする事は可能でしょうか?

現状の設計ですと、WebサービスVIPからVRRP VIPまでのルーティングがSPOFになってしまいます。もし、VRRPのVIPの80番を叩くことでロードバランスが可能でしたらSPOFを取り除く事が出来ます。

記事公開から時間が経っておりますのでお返事をいただけるか分かりませんが、ご一考下されば幸いです。
7. Posted by nandekana   2011年01月07日 01:38
3 WinXP SP2の環境で、

clientがWindowsの場合はコマンドプロンプトから
C:\>route add 10.10.31.100 mask 255.255.255.255 10.10.31.10

これを試したら、
The route addition failed: Either the interface index is wrong or the gateway does not lie on the same network as the interface. Check the IP Address Table for the machine.
なんてゆうエラーが出てしまいました。。

この記事にコメントする

名前:
URL:
  情報を記憶: 評価: 顔   
 
 
 
Blog内検索
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント
最新トラックバック
Archives