LVSを使ったブローカーの構築：ブローカーの障害時の動作確認

今回はブローカーの動作について確認を行いますが、
動作確認に進む前に現状の構成のおさらいをしましょう。

現在までの正系ノード、副系ノードの二つのノードで構成されたブローカーが存在しています。

基本的に正系ノードが正常な場合、
クライアントからのアクセスを受け付ける仮想IP（10.1.100.100）は正系ノードに割り当てられており、
副系ノードはいわゆる待機ノードとなっています。

正系ノードが正常であれば上図の状態なわけですが、
正系ノードに何からの理由で障害が発生した場合、その時点で仮想IPは待機系ノードに割り当てられます。

このように仮想IPが副系ノードに割り当てられることでサービスが継続できる仕組みとなっています。

今回は上図のようなノードの切替も含めた動作の確認を実際に行い、
LVS+keepalivedを利用して構築したブローカーの動作を理解します。

今回の説明の順番は以下の通りです。

1. 正系ノード障害時の動作確認
2. 副系ノード動作時の正系ノード復旧時の動作確認
3. 未接続の実サーバに障害が発生した場合の動作
4. 接続中実サーバに障害が発生した場合の動作

では説明に入ります。

1.正系ノード障害時の動作確認

まずは、正系ノードの障害時の動作を確認します。
障害としては、様々なケースが想定されますが、今回は正系ノードをシャットダウンさせ、
その状況下の正副ノードの状態を確認します。

なお、開始前の状態は｢LVSを使ったブローカーの構築：LVSの副系ノードの構築｣内の
｢(1-4) keepalivedの起動と設定｣の状態と同様で、
仮想IPは正系ノードに割り当てられており、副系ノードは待機中の状態となっています。

では、早速正系ノード（vm06:10.1.100.160）をシャットダウンしますが、
簡易的なチェックとしてノード切替の間、仮想IP（10.1.100.100）に対して
pingを打ち続けてみましたので、その結果も合わせて確認します。

まず、ノード切替後（正系ノードがシャットダウンされた状態）での
副系ノードの状態は以下のようになりました。

予定通り、仮想IP（10.1.100.100）が副系ノード(vm07:10.1.100.170)に割り当てられました。

この切替中のPingの結果は以下の通りです。

切替時に特にタイムアウト等は発生しませんでしたが、
シーケンス番号（icmp_seq）の115の時に｢time=4.02ms｣となっており、
ここで一番応答時間がかかっていることから、
おそらくここで仮想IPの割当が変わったということが予想されます。

なお、あえて確認結果は表示しませんが、
仮想IPが副系ノードに割り当てられた状態で、MySQLサーバへの接続の為に、
仮想IPの3306ポートに接続を行っても正常に実サーバへの転送が行われ
正系ノードと同様にサービスが継続できていることがわかります。

2.副系ノード動作時の正系ノード復旧時の動作確認

さて｢1.正系ノード障害時の動作確認｣を確認した状態で
今度は障害の発生した正系ノードを復旧させてみます。

現在の設定内容では、説明上わかりやすくする為に｢正系ノード｣や｢副系ノード｣といった
名前をあえて利用していますが、設定上は両ノードに区別はありません。

これは、私も知らなかったのですが、
｢keepalived.conf｣の｢state｣をいずれも｢BACKUP｣に設定し、
｢nopreempt｣とし、プリエンプティブモードを無効にすることで、
先に起動した方が正系ノード（設定でいう｢MASTER｣）になるとのことでした。
（この辺の設定はKLab様の｢ロードバランサの冗長化｣を参考にいたしました）

想定通りならば、仮想IPの割当は副系ノード(vm07:10.1.100.170)のままで、
起動した正系ノードには割り当てられない状態になるはずです。

上図を見てもわかるかと思いますが、再起動を行った正系ノード（vm06:10.1.100.160）には
想定通り仮想IPが割り当てられませんでした。

さて、ここまでの確認でブローカーであるノードの障害については
その動作について理解していただけたのではないかと思います。

次は実際にサービスを提供する実サーバ（ここではMySQLサーバ）に
何らかの障害が発生した場合にどのような動作となるのかという点について確認します。

3.未接続の実サーバに障害が発生した場合の動作

まず最初はクライアントが未接続の実サーバに障害が発生した場合の動作について
念のため確認を行うことにします。

想定する動作としては、実サーバとしてMySQLサーバが2台存在する場合
正常時であればラウンドロビングの設定になっている為、
二つのサーバが交互に割り当てられます。
これが、一方のサーバに障害が発生した場合は、
その障害をブローカーが検知し、該当の実サーバにクライアントからの接続を
転送させない（つまり、正常な実サーバのみに転送を行う）状態になれば
想定通りの動作を行ったことになります。

まず、正常な状態で、クアライアント1台目から順に接続し、3台目まで接続した結果を掲載します。

上から、1台目接続時点、2台目接続時点、3台目接続時点です。

見ていただければわかると思いますが、正常な状態であればラウンドロビング先の実サーバとして、
｢10.1.100.150:mysql｣と｢10.1.100.140:mysql｣が存在しており、
クライアントからの要求に応じて交互に振り分けています。
※｢ActiveConn｣のカウンターが増加していくことから上記がわかります。

では、今度は実サーバのうちの一台を落として、同様に3台目まで接続を行ってみます。

まずは｢10.1.100.150:mysql｣のMySQLサーバのサービスを落として接続できない状態にします。

>mysqladmin shutdown

この時点でipvsadmではどのように表示されるのか念のため確認します。

既に振り分け先に｢10.1.100.150:mysql｣が存在しません。

では、早速接続を行ってみます。

｢10.1.100.140:mysql｣のサーバのみに接続が行われていることがわかります。

これで接続先の実サーバ（MySQLサーバ）に障害が発生している場合は、
その状態をブローカーが検知し、障害サーバには振り分けを行われないことがわかったと思います。

4.接続中実サーバに障害が発生した場合の動作

さて、今回は｢3.未接続の実サーバに障害が発生した場合の動作｣とは異なり、
クライアントが接続している先の実サーバに障害が発生した場合どうなるかという点を確認します。

なお、本検証の内容は、接続先実サーバと接続に用いるクライアントの接続方式により
結果が異なってきますので、その点はご理解ください。

まず、実サーバを2台とも正常稼動させた上で、クライアント３台を接続します。

その状態で実サーバ｢10.1.100.140:mysql｣のネットワーク（eth0）をダウンさせます。

>ifdown eth0

この状態でipvsadm上では以下のように表示されています。

クライアントが1台接続されていた｢10.1.100.140:mysql｣が先ほどの操作で
ラウンドロビング先からはずされていることがわかります。

では、この状態でクライアントではどのような状態になるのでしょうか？

クライアント側では、実サーバが停止した後に｢show databases;｣を実行しています。
しかし、｢ERROR 2013 (HY000) : Lost connection to MySQL server during query｣と
エラーメッセージが表示されているようにサーバとの接続が切断された為
クエリーの実行に失敗しています。
なお、実際はコマンドを入力してからクライアント側で設定しているタイムアウトするまで
クライアント側では応答待ち状態になっています。

これは、今回構築したブローカーの特徴ですが、
あくまでもブローカーは正常サーバへの振り分けを行っているに過ぎない為、
振り分けされた後のサーバとの間でコネクションを永続的に張った場合は、
その接続先の実サーバの状態に左右されます。

逆に言えば、都度コネクションを張るような仕組みである場合は、
上記のような問題は基本的には発生しないと考えてよいでしょう。

以上の検証を持ってMySQL Clusterに関する説明を終了します。

なお、説明を行っていない｢keepalived.conf｣の各設定内容に関する説明については
｢LVSを使ったブローカーの構築：｢keepalived.conf｣についての説明｣にて行っておりますので
ご興味のある方はご一読いただければと思います。

お疲れ様でした。

Technorati Tags: keepalived, MySQL, Cluster, ブローカー