2009年6月24日水曜日

[Clustcom News] keepalivedで行うVRRPフェイルオーバー

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…☆
Clustcomニュースレター No.11  2009.6.24発行
             クラスターコンピューティング株式会社
☆…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
# このメールは、WEBページから配信登録いただいたお客様、
# 過去に弊社に資料請求いただいたお客様、弊社スタッフと名刺交換を
# させていただいたお客様に配信しています。
# 配信停止手続きにつきましては、文末に記載させていただいております。


こんにちは。
Clustcomメルマガ担当の國生和栄です。


一年で一番の雨の季節ですね。
 と、言うのも、日本には三つの雨期があります。


 ひとつはもちろん、この季節にやってくる梅雨です。
 あとは、春雨と秋雨。
 春、夏、秋、と季節のたびにまとまった雨が降っているんですね。


 梅雨のこの時期は、気温も次第に上がり、じめじめした空気を払拭する
ために、エアコンで除湿や冷房をかけている場所も増えてきます。


 雨がかかって湿った衣服でいると、意外に寒く感じる瞬間もあります。
 風邪にはくれぐれもお気をつけください。


 梅雨が終われば、夏本番ですね!
 後記ではこの時期のオススメデートをご紹介します。


さて、本日のトピックです。


┌──Newsletter_Topic ─────────────────────┐


■【Topics】keepalivedで行うVRRPフェイルオーバー
■提供サービスのご案内


└──────────────────────Newsletter_Topic ─┘


┏┓
┗■ 【Topics】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★


━ keepalivedで行うVRRPフェイルオーバー ━━━━━━



弊社では、Linuxベースの負荷分散技術LVSを利用し、負荷分散システムの
構築を行っています。

LVSはLinuxカーネルのipvsの機能を利用し、あるサーバに来た
TCP/UDPパケットを複数のサーバに振り分ける技術です。
HTTPアクセスを複数のWEBサーバに振り分ける場合等によく使われます。


LVSを利用する上で欠かせないのが、keepalived(http://www.keepalived.org/)
という優れものプログラムです。


keepalivedには、次の二つの機能があります。


★ ipvsの振り分けテーブルを、振り分け先サーバの死活状態をチェックし、
動的に設定する、Healthcheck機能
★ パケットの振り分けを行うサーバ自体をフェイルオーバーさせる、VRRP機能



今回は、ふたつめのVRRPの動作をおおざっぱに解説したいと思います。



VRRPはRFC3768(http://www.ietf.org/rfc/rfc3768.txt)
で定義されたプロトコルで、ものすごく大まかにいうと次の様なものです。


二台のサーバは、VRIPというIPアドレスをシェアし、一方がMASTER、もう一方が
BACKUP状態になります。
MASTER状態のサーバはVRIPをネットワークインターフェースにセットし、
VRRPアドバタイズパケットを、例えば1秒間隔で送信し続けます。
この時、BACKUP状態のサーバはVRRPアドバタイズパケットを黙って聴き続け、
何も行動を起こしません。


MASTER状態のサーバに障害が起こり、VRRPアドバタイズパケットがある一定の
期間途切れるか、priority=0のVRRPパケットが流れると、BACKUP状態のサーバ
は、新たに自らがMASTER状態に昇格し、VRRPアドバタイズパケットを送信しま
す。
この時、新MASTERはVRIPを自身のインターフェースにセットし、
Gratuitous ARPを送信することで、VRIP宛のパケットが元のMASTERではなく、
自分のところに送られてくるように仕向けます。


以上の仕組みにより、クライアントPCは元のMASTERサーバに障害が起こった
場合でも、何の設定変更も無しで新しいMASTERにパケットを送信することが
できます。



それでは、実際にkeepalivedでVRRPを動かす方法を見てみましょう。


KeepalivedでVRRPを動かすには、二台のサーバで設定ファイルを用意し、
keepalivedを起動すればOKです。


設定ファイル/etc/keepalived/vrrp.confの内容例
vrrp_instance VI_1 {
nopreempt
state BACKUP
interface eth0
garp_master_delay 3
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {
192.168.20.115
}
}
priorityの値は通常1-254の値を選ぶことができ、二台のサーバで異なる値を
設定します。
VRRPのRFCによると同じpriority値を設定しても問題ないはずですが、
keepalivedの場合には、同じ値は避けないとまずいことになります。


これについては次回詳しく説明します。


"state BACKUP"はVRRPの初期状態をBACKUPにしてしていて、プログラム起動の
直後にいきなりMASTERになってしまわないようにしています。
virtual_ipaddress {192.168.20.115}はVRIPアドレスで、MASTER状態のサーバ
のみが自分のネットワークインターフェースにセットします。



二台のサーバで順次以下のコマンドを実行してみましょう。
/sbin/keepalived -nPf /etc/keepalived/vrrp.conf


シスログにいくつかログが記録されますが、【BACKUP】【MASTER】という
キーワードを特に注意して見ると良いでしょう。


Jun 24 12:02:45 a Keepalived: Starting Keepalived v1.1.17 (06/24,2009)
Jun 24 12:02:45 a Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
Jun 24 12:02:49 a Keepalived_vrrp: VRRP_Instance(VI_1) Transition to
MASTER STATE
Jun 24 12:02:50 a Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE



先に起動したサーバaのログを見ると、一旦BACKUP状態に入ったのちMASTERに昇
格したことが分かります。


その後で、もう一方のサーバbを起動すると、まずBACKUP状態に入り、そのまま
の状態でいます。


Jun 24 12:03:06 b Keepalived: Starting Keepalived v1.1.17 (06/24,2009)
Jun 24 12:03:06 b Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE



この時サーバa,bそれぞれでIPアドレスを見ると、
サーバaにのみVRIP=192.168.20.115がセットされていることが分かります。


a:# ip add show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:f6:44:dd brd ff:ff:ff:ff:ff:ff
inet 192.168.20.114/24 brd 192.168.20.255 scope global eth0
inet 192.168.20.115/32 scope global eth0

b:# ip add show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:c5:c0:b9 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.225/24 brd 192.168.20.255 scope global eth0


ここで先に起動したサーバaのkeepalivedをCtrl-Cで終了させると、サーバbが
新たにMASTERに昇格しVRIPを引き継ぎます。


Jun 24 12:06:03 b Keepalived_vrrp: VRRP_Instance(VI_1) Transition to
MASTER STATE
Jun 24 12:06:04 b Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE


この時、"tcpdump -n vrrp or arp"で見たVRRPアドバタイズパケットの様子が以
下の通りです。
サーバa(192.168.20.114)からVRRPパケットが送信されている状態で、
keepalivedをCtrl-cで終了(12:06:02)、その直後にサーバaから"prio 0"のVRRP
パケットが送信され、すぐにサーバb(192.168.20.225)からVRRPパケットが送信
されていることがよく分かると思います。


12:06:01.726925 IP 192.168.20.114 > 224.0.0.18: VRRPv2, Advertisement,
vrid 51, prio 100, authtype none, intvl 1s, length 20
12:06:02.730941 IP 192.168.20.114 > 224.0.0.18: VRRPv2, Advertisement,
vrid 51, prio 100, authtype none, intvl 1s, length 20
12:06:02.880531 IP 192.168.20.114 > 224.0.0.18: VRRPv2, Advertisement,
vrid 51, prio 0, authtype none, intvl 1s, length 20
12:06:03.101168 IP 192.168.20.225 > 224.0.0.18: VRRPv2, Advertisement,
vrid 51, prio 200, authtype none, intvl 1s, length 20
12:06:04.105220 arp who-has 192.168.20.115 (ff:ff:ff:ff:ff:ff) tell
192.168.20.115
12:06:04.105269 arp who-has 192.168.20.115 (ff:ff:ff:ff:ff:ff) tell
192.168.20.115
12:06:04.105312 arp who-has 192.168.20.115 (ff:ff:ff:ff:ff:ff) tell
192.168.20.115
12:06:04.105348 arp who-has 192.168.20.115 (ff:ff:ff:ff:ff:ff) tell
192.168.20.115
12:06:04.105390 arp who-has 192.168.20.115 (ff:ff:ff:ff:ff:ff) tell
192.168.20.115
12:06:04.105442 IP 192.168.20.225 > 224.0.0.18: VRRPv2, Advertisement,
vrid 51, prio 200, authtype none, intvl 1s, length 20
12:06:05.109135 IP 192.168.20.225 > 224.0.0.18: VRRPv2, Advertisement,
vrid 51, prio 200, authtype none, intvl 1s, length 20
12:06:06.109204 IP 192.168.20.225 > 224.0.0.18: VRRPv2, Advertisement,
vrid 51, prio 200, authtype none, intvl 1s, length 20



12:06:04に5個連続で流れているarpパケットはGratuitous ARPと呼ばれるもの
で、同一イーサネットセグメントにある機器のARPキャッシュを更新する役割を
果たします。


それぞれのアドレスを見ると、今度はサーバbのみにVRIP=192.168.20.115がセッ
トされていることが分かります。
a:# ip add show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:f6:44:dd brd ff:ff:ff:ff:ff:ff
inet 192.168.20.114/24 brd 192.168.20.255 scope global eth0

b:# ip add show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:c5:c0:b9 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.225/24 brd 192.168.20.255 scope global eth0
inet 192.168.20.115/32 scope global eth0



サーバbが新MASTERになり、VRIPを引き継ぐことができました。
以上で、keepalivedのVRRP機能の大まかな動作確認ができました。


意外と簡単だったのではないでしょうか?
皆さんも試してみてはいかがでしょうか。


実際には、上の説明とは違う動作モードが選べたり、keepalivedの実装に
起因する落とし穴がいくつかあったり、知らなければいけないことが
たくさんあります。
それはまた機会がありましたら解説したいと思います。


 


┏┓
┗■ 【提供サービスのご案内】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★


1)サーバの販売


  使用方法に応じたサーバを提案、販売しています。


  http://www.clustcom.com/melma0111



2)LVS負荷分散システムの設計/構築


  複数サーバの快適な応答速度のため、ロードバランサーの
  システムを設計し、構築します。


  http://www.clustcom.com/melma0112


3)完全冗長ソリューションの設計/構築 


  ネットワークを冗長化し、障害発生を避けるためのシステムを
  設計し、構築します。


  http://www.clustcom.com/melma0113




「携帯電話を含むインターネット事業へ業務を拡大しようかな」
「すでに持っているサーバの調子が悪いみたい」
「サーバの反応が悪いと利用者に言われるけれど」


 そんなときに思い出していただけたら・・・。


 クラスターコンピューティング(株)は、サーバ販売と、サーバを
快適に動かすシステムを作っている会社です。  


 
━=━=━=━=━=━=━=━=━=━=━=━=━=━=━=━=━=━


【お便り募集】


読者の皆様からのお便りを募集しています。
 ご感想、ご質問などをお寄せください。


日ごろ疑問に感じていること、専門的な疑問、なんでもかまいません。
 もちろん、基本的なことも大歓迎です! 


紙面掲載させていただいた場合には、プレゼントを差し上げます。

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏


 ■クラスターコンピューティング(株)ホームページ
http://www.clustcom.com/


 ■clustcom かわらばん (ブログ)
http://kawaraban.clustcom.com/


 ■社長の独り言日記 (社長ブログ)
http://ktaka.blog.clustcom.com/


 ■メルマガアーカイブ (メルマガバックナンバー)
http://marc.clustcom.com/



┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
 
いかがでしたでしょうか?
お役に立つ情報はありましたでしょうか?


 さて、後記です。


 6月も半ばを過ぎて、2009年も半分が過ぎようとしています。
 今年も残すところ、あと6ヶ月になってしまいました。


 この時期、半年間で溜まった厄を落とすための【夏越の祓え】が
神社で行われますね。
 
 夏の暑さで病気になりやすい時期に、心身の健康を祈って行われる
もので、茅(ちがや)で作った輪を神社の境内に設置して、それをくぐる
【茅の輪(ちのわ)くぐり】を行うのが特徴です。


 紙で作った人形(ひとがた)で調子の悪い部分を撫でて、川に流し
たり、燃やしたりする風習も残っています。
 茅の輪くぐりは大晦日にも行われますが、夏冬ともに、全国の神社で
設置されるわけではなく地域差もあるようです。


夏越の祓えは、畿内(京都・大阪・奈良あたり)で特に盛んな風習で、
7月の末に行われます。
 関東地方でも行われており、そちらは6月末に行われるようですね。


 そもそも夏越の祓えは、旧暦6月、水無月に行わる神事です。
 新暦ですと、7月から8月にかけての頃になります。


 【夏越の祓え】は浴衣デートに最適です。


 何故なら、女の子は夏場に浴衣を着たいのですが、花火大会以外では
着ていく場所がないから!です。


 そこで、この機会に、意中の人や恋人を誘って夕暮れ時に参拝。
 後はまったり飲みデートなんてどうでしょう。
  


次回は7月5日頃に配信予定です。お楽しみに!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ このメールの送信者
クラスターコンピューティング株式会社
〒194-0014 東京都町田市高ヶ坂803 番地
TEL:042-722-7702 FAX: 042-851-5716


クラスターコンピューティング株式会社は
Linuxで、ネットワーク・サーバインフラを作っている会社です。


■ 配信停止
配信停止は、お手数ですが以下のページからお願いいたします 
http://www.clustcom.com/melma/unsub/


Copyright(C) 2008 Cluster Computing ,Inc. All Rights Reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# このメルマガの本文は著作権により保護されていますが、もし、
あなたのお役に立てるのであれば、ご自由に転載していただいて
構いません。その際には「Clustcomニュースレターによると。。。」と、
出典を明らかにするようお願いいたします。


■ どうぞ、ご友人にもご自由に転送してください。
■ 配信登録はこちらから
http://www.clustcom.com/melma/sub/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━