Clustcomニュースレター No.12 2009.7.13発行
クラスターコンピューティング株式会社
☆…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
# このメールは、WEBページから配信登録いただいたお客様、
# 過去に弊社に資料請求いただいたお客様、弊社スタッフと名刺交換を
# させていただいたお客様に配信しています。
# 配信停止手続きにつきましては、文末に記載させていただいております。
こんにちは。
Clustcomメルマガ担当の國生和栄です。
夏の食べもので、みなさんが食べたいものは何でしょうか？
私が夏に食べたいものは、鱧です。ハモ。
ウナギ目・ハモ科。
これもまた、関西ではメジャーで、関東ではマイナーな食材だそうです。
関西から関東に移って一年、またしても新事実です（私的には）。
ハモはウナギと似ているのですが、するどい歯を持ち、獰猛です。
小骨が多いのでウナギのようにさばいた後、細かく包丁の刃を入れる
「骨切り」と呼ばれる下処理が必要になります。
骨切りを施したハモを熱湯に通すと、身がふわりと反り返って白い花の
ように開きます。湯引きハモです。
梅肉やからし酢味噌で食べるのですが、ハモはウナギと違ってさっぱり
淡白な味。
京都では祇園祭の頃の京料理のおしながきに載ります。
鴨川の夜風に吹かれながら、からし酢醤油の湯引きハモに、
常温の辛口日本酒。
「夏っていいね」の一瞬です。
今号のあとがきでは、引き続き、夏の風物詩を・・・。
さて、本日のトピックです。
┌──Newsletter_Topic ─────────────────────┐
■【Topics】VRRP、こんな失敗大変だ
■提供サービスのご案内
└──────────────────────Newsletter_Topic ─┘
┏┓
┗■ 【Topics】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★
━ VRRP、こんな失敗大変だ ━━━━━━
前号で、【keepalivedのVRRP機能】について簡単に解説しました。
keepalivedもいろいろテストして使わないと思わぬ挙動を示すことがあります。
思い通りに動作しない場合、コードの修正も必要になってきます。
今回は、私、高橋がVRRPのpriorityでハマった事例をご紹介したいと思います。
VRRPのRFC3768には、Preempt_Modeという動作モードが定義されています。
これがTrueだと、priorityが高いサーバがBACKUP状態にある場合、
priorityの低い今のMASTERに成り代わり、MASTERに昇格しようとします。
私の心の中では、【どけどけモード】と呼んでいます。
keepalivedの場合、Preempt_Modeはnopreemtという設定パラメータで
制御されています。
nopreemptがtrueだとPreempt_Modeはfalse
nopreemptがfalseだとPreempt_Modeはtrue
ちょっとややこしいですね。
私の脳内では、nopreemptのことを【控えめモード】と呼んでいます。
【popreemptがセットされている=控えめモード】
【nopreemptがセットされていない=どけどけモード】
と考えると理解し易いです。
では、実際にnopreempt有り無しの動作を見てみましょう。
サーバaのpriority = 200
サーバbのpriority = 100
だとします。
サーバbのkeepalivedが先にMASTERとして稼働している状態で、
サーバaのkeepalivedを立ち上げます。
【nopreempt無し=どけどけモードの場合】
◆aのログ◆
Jul 10 13:53:29 a Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
Jul 10 13:53:30 a Keepalived_vrrp: VRRP_Instance(VI_1) forcing a new
MASTER election
Jul 10 13:53:31 a Keepalived_vrrp: VRRP_Instance(VI_1) Transition to
MASTER STATE
Jul 10 13:53:32 a Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
◆bのログ◆
Jul 10 13:53:30 b Keepalived_vrrp: VRRP_Instance(VI_1) Received higher
prio advert
Jul 10 13:53:30 b Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
bに成り代わり、aがMASTERになりました。
【nopreemptあり=控えめモードの場合】
◆aのログ◆
Jul 10 13:58:02 a Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
aはBACKUP状態に入り、おとなしくしています。
ここまででnopreemt有り無しでの動作が確認できました。
さて、ここからが本題の【ハマり事例】です。
【控えめモード】と【どけどけモード】とどちらを選ぶのかは、
運用のポリシー次第です。
しかし、すぐに思い浮かぶ懸念があります。
LANのコネクタが接触不良か何かで、ネットワークリンクがアップダウンを
繰り返してしまったら、どうなるのでしょう。
【どけどけモード】だと、
サーバaのLANコネクタが接触不良を起こすと、aがMASTERになったり、
bがMASETRになったりを繰り返すでしょう。
【控えめモード】だと、bがMASTERになれば、サーバaのLANコネクタが
接触不良を起こしても、MASTER昇格を繰り返すことはなさそうです。
「控えめモード」の方が良さそうな気がします。
それでは、ネットワークリンクをアップダウンさせた場合の挙動を見てみましょう。
サーバaのpriority = 200
サーバbのpriority = 100
nopreemptあり=控えめモード
にします。
bがMASTER、aがBACKUPの状態で、aのネットワークリンクをダウンさせ、
しばらくして再びアップさせてみます。
a:~# ip link set dev eth0 down ; sleep 10 ; ip link set dev eth0 up
すると、それぞれのサーバのsyslogには次のようなメッセージが現れます。
◆aのログ◆
Jul 10 14:00:54 a Keepalived_vrrp: Kernel is reporting: interface eth0 DOWN
Jul 10 14:00:54 a Keepalived_vrrp: VRRP_Instance(VI_1) Now in FAULT state
Jul 10 14:01:02 a Keepalived_vrrp: VRRP_Instance(VI_1) prio is higher
than received advert
Jul 10 14:01:02 a Keepalived_vrrp: VRRP_Instance(VI_1) Transition to
MASTER STATE
Jul 10 14:01:03 a Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
◆ｂのログ◆
Jul 10 14:01:02 b Keepalived_vrrp: VRRP_Instance(VI_1) Received higher
prio advert
Jul 10 14:01:02 b Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
控えめモードにもかかわらず、aがMASTERになり、bがBACKUPになってしまいました。
keepalivedでネットワークリンクがダウンするとFAULT Stateに入ります。
ネットワークリンクがアップするとFAULT Stateからいきなり、MASTERに昇格し
てしまい、nopreemptが
効いていないようです。
FAULT StateはVRRPのRFCには無い独自ステートなのですが、
リンクアップ時にいきなりMASTERになるのではなく、nopreemptの有り無しに
従って欲しいところです。
いろいろ調べた挙句、この対策は、以下の二通りあることがわかりました。
1. keepalivedのコードを直す
2. priorityを同じにして使う
実は1.が簡単で、手前味噌ながら、たった１行の修正で直ってしまいます。
http://marc.info/?l=keepalived-devel&m=117544330102632&w=2
(是非、お試し下さい。)
コードの修正を好まないお客様には、2.の方法をお勧めしていました。
aのpriorityをbと同じ100にしてリンクのダウン→アップを行ってみます。
◆aのログ◆
Jul 10 14:33:27 a Keepalived_vrrp: Kernel is reporting: interface eth0 DOWN
Jul 10 14:33:27 a Keepalived_vrrp: VRRP_Instance(VI_1) Now in FAULT state
Jul 10 14:33:35 a Keepalived_vrrp: Kernel is reporting: interface eth0 UP
aのログに上のメッセージが残るだけで、aがMASTERに昇格してしまうことは
ありません。
めでたしめでたしと思いましたが、実はpriorityを同じにする方法には落とし穴が
あったのです。
さて、紙面と時間がつきてしまったので、今回はこの辺にしておきたいと
思います。
あんまり、もったいをつけるなと言う向きのために予告をしますと、
keepalivedの実装にバグというか不十分な部分があって、
priorityを同じにすると、ある条件の元に両方がMASRERになってしまうという、
トンでもない事件が起こってしまうのです。
次回をお楽しみに。
┏┓
┗■ 【提供サービスのご案内】
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━★
１）サーバの販売
使用方法に応じたサーバを提案、販売しています。
http://www.clustcom.com/melma0121
２）LVS負荷分散システムの設計/構築
複数サーバの快適な応答速度のため、ロードバランサーの
システムを設計し、構築します。
http://www.clustcom.com/melma0122
３）完全冗長ソリューションの設計/構築
ネットワークを冗長化し、障害発生を避けるためのシステムを
設計し、構築します。
http://www.clustcom.com/melma0123
「携帯電話を含むインターネット事業へ業務を拡大しようかな」
「すでに持っているサーバの調子が悪いみたい」
「サーバの反応が悪いと利用者に言われるけれど」
そんなときに思い出していただけたら・・・。
クラスターコンピューティング（株）は、サーバ販売と、サーバを
快適に動かすシステムを作っている会社です。
━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━＝━
【お便り募集】
読者の皆様からのお便りを募集しています。
ご感想、ご質問などをお寄せください。
日ごろ疑問に感じていること、専門的な疑問、なんでもかまいません。
もちろん、基本的なことも大歓迎です！
紙面掲載させていただいた場合には、ささやかなプレゼントを差し
上げます。
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
■クラスターコンピューティング(株)ホームページ
http://www.clustcom.com/
■clustcom かわらばん （ブログ）
http://kawaraban.clustcom.com/
■社長の独り言日記 （社長ブログ）
http://ktaka.blog.clustcom.com/
■メルマガアーカイブ （メルマガバックナンバー）
http://marc.clustcom.com/
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
いかがでしたでしょうか？
お役に立つ情報はありましたでしょうか?
さて、後記です。
意外と夏休みのある８月が夏という感覚が蔓延してますが、お盆を
過ぎると海にも入れなくなってしまうので、やっぱり日本の夏は梅雨明け
からお盆まで！と思っています。
日本の夏の暑さは長いけれど、季節としての夏は意外と短いのですね。
そして夏と言えば、肝試し。そして怪談話ですね。
夏に怪談話をすると、ちょっとひやっとしますが、夜も人通りが
多かったり、絶えず虫が鳴いているのが騒がしく、それほどこわさを感じずに
済みます。
私はこわがりなのに、怪談を聞きたがるタイプです。
やめとけば良いのに、ひやっとしてみたくて参加してしまい・・・。
聞いた後は、びびりまくって、周りからは「やめとけばいいのに」と
言われ通しです。
このメルマガをお読みの方は、理系の方が多いと思いますので
「おばけなんていないよ〜。科学ですべては解明できる！」という
考え方でしょうか。
そんなことないやい！と文系の私は思うのですが。
ですが、最近、私の理系友人が【怪談を怖く話すコツ】を教えてくれ、
妙に納得しましたのでご紹介します。
それは、怪談をする前に、
「いまからこわい話をするよ」
と、言うことなのだそうです。
その瞬間、人は自分の記憶の中にある「こわい」ことを想像し、
今からこわい疑似体験するという準備が脳内でなされてしまうのだそうです。
私は想像力豊かすぎる文系なので、事実、この一言だけで
もう十分「こわい」です。単純ですね。
理系の友人は、「だから実際はこわいはずないの」と言いましたが、やっぱり
こわいんです。
怪談の仕組みよりも、こわい気持ちを消滅させる方法を知りたい、この夏です。
ご存知の方はご一報を！！
次回は7月20日頃に配信予定です。お楽しみに！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ このメールの送信者
クラスターコンピューティング株式会社
〒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/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━