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の実装に
起因する落とし穴がいくつかあったり、知らなければいけないことが
たくさんあります。
それはまた機会がありましたら解説したいと思います。
┏┓
┗■ 【提供サービスのご案内】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★
１）サーバの販売
使用方法に応じたサーバを提案、販売しています。
http://www.clustcom.com/melma0111
２）LVS負荷分散システムの設計/構築
複数サーバの快適な応答速度のため、ロードバランサーの
システムを設計し、構築します。
http://www.clustcom.com/melma0112
３）完全冗長ソリューションの設計/構築
ネットワークを冗長化し、障害発生を避けるためのシステムを
設計し、構築します。
http://www.clustcom.com/melma0113
「携帯電話を含むインターネット事業へ業務を拡大しようかな」
「すでに持っているサーバの調子が悪いみたい」
「サーバの反応が悪いと利用者に言われるけれど」
そんなときに思い出していただけたら・・・。
クラスターコンピューティング（株）は、サーバ販売と、サーバを
快適に動かすシステムを作っている会社です。
━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━
【お便り募集】
読者の皆様からのお便りを募集しています。
ご感想、ご質問などをお寄せください。
日ごろ疑問に感じていること、専門的な疑問、なんでもかまいません。
もちろん、基本的なことも大歓迎です！
紙面掲載させていただいた場合には、プレゼントを差し上げます。
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
■クラスターコンピューティング(株)ホームページ
http://www.clustcom.com/
■clustcom かわらばん （ブログ）
http://kawaraban.clustcom.com/
■社長の独り言日記 （社長ブログ）
http://ktaka.blog.clustcom.com/
■メルマガアーカイブ （メルマガバックナンバー）
http://marc.clustcom.com/
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
いかがでしたでしょうか？
お役に立つ情報はありましたでしょうか?
さて、後記です。
６月も半ばを過ぎて、２００９年も半分が過ぎようとしています。
今年も残すところ、あと６ヶ月になってしまいました。
この時期、半年間で溜まった厄を落とすための【夏越の祓え】が
神社で行われますね。
夏の暑さで病気になりやすい時期に、心身の健康を祈って行われる
もので、茅（ちがや)で作った輪を神社の境内に設置して、それをくぐる
【茅の輪（ちのわ）くぐり】を行うのが特徴です。
紙で作った人形（ひとがた）で調子の悪い部分を撫でて、川に流し
たり、燃やしたりする風習も残っています。
茅の輪くぐりは大晦日にも行われますが、夏冬ともに、全国の神社で
設置されるわけではなく地域差もあるようです。
夏越の祓えは、畿内（京都・大阪・奈良あたり）で特に盛んな風習で、
７月の末に行われます。
関東地方でも行われており、そちらは６月末に行われるようですね。
そもそも夏越の祓えは、旧暦６月、水無月に行わる神事です。
新暦ですと、７月から８月にかけての頃になります。
【夏越の祓え】は浴衣デートに最適です。
何故なら、女の子は夏場に浴衣を着たいのですが、花火大会以外では
着ていく場所がないから！です。
そこで、この機会に、意中の人や恋人を誘って夕暮れ時に参拝。
後はまったり飲みデートなんてどうでしょう。
次回は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/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━