keepalivedでフェイルバック無効にしたときの挙動〜LANケーブル障害編〜
以前のエントリ『keepalivedでフェイルバック無効(nopreempt)にしたときの挙動』では、以下のような状況でフェイルバックするかどうかの確認をしました。
- keepalivedサービスが停止し、マスタからスレーブに仮想IPが引き継がれた後に元マスタのkeepalivedサービスを起動したとき
- keepalivedでヘルスチェックしているインタフェースを意図的にダウンさせ、スレーブに仮想IPが引き継がれた後にインタフェースをアップさせたとき
keepalivedの振る舞いとして、フェイルバック無効の設定をしている場合は、keepalivedを先に起動した側が常にマスタとなるということから、前者の場合はフェイルバックしないことが確認できました。
しかし後者の場合は、keepalivedのサービスは停止していないため、フェイルバックしてしまうことを確認することができました。
以前のエントリでは、LANケーブルが抜けたり、使えなくなったりする障害時の振る舞いについては、おそらくフェイルバックするであろうと私の意見を書いていました。
しかし、試してみないことにはkeepalivedの挙動はわかりませんので、実際に動作確認をしてみました。
それでは、念のため環境のおさらいから。
まずはじめに、Linux Server1のkeepalivedを始めに起動し、そのあとにLinux Server2にてkeepalivedを立ち上げることでLinux Server1に仮想IPアドレスが割り当てられるようにします。
#仮想IPは $ /sbin/ip addr で割り当てられているかどうか確認できます。
今回は、Linux Server1のサービスセグメントに192.168.2.1と192.168.2.2、バックエンドセグメントに10.1.2.1の仮想IPが割り当てられているものとします。
動作確認では、bondingを組んでいる場合とそうでない場合のそれぞれでLinux Server1に繋がっているLANケーブルを抜き、フェイルオーバした後にLANケーブルを再接続し、挙動がいづれも同一であることも確認します。
[検証1] マスタ(Linux Server1)のbond0に繋がるLANケーブルを抜いた場合
Linux Server1にてeth0とeth2でbondingを組んでいますが、それぞれに繋がるLANケーブルを抜きます。
フェイルオーバしたことを確認して、任意のサービスにアクセスできることを確認します。
今回は、Rails製の社内SNSであるSKIPをテストアプリケーションとし、各セグメントに割り当てられた仮想IPで、SKIPにアクセスできるかどうかで、正しくフェイルオーバできているかどうかを確認しました。
フェイルオーバ後、多少時間をおいて、抜いていたLANケーブル2本を再度、Linux Server1のeth0、eth2につなげました。
すると、Linux Server2に仮想IP(192.168.2.1と10.1.2.1)が割り当てられたままフェイルバックすることはありませんでした。
そのため、両サーバにてtcpdumpでパケット解析をしていてもGARPパケットを受信することはありませんでした。
[検証2] マスタのeth1に繋がるLANケーブルを抜いた場合
[検証1]と同様の手順で、下記の図の赤色×部分のLANケーブルを抜いて、フェイルオーバしたことを確認してから、再度LANケーブルをつなげました。
こちらも[検証1]の結果と同様、フェイルバックしないことが確認できました。
結論
検証1、2の結果より、前回のエントリの結論+αの結果を得ることができました。
(1) keepalivedサービスが停止し、マスタからスレーブに仮想IPが引き継がれた後に元マスタのkeepalivedサービスを起動したとき
⇒フェイルバックしない
(2) keepalivedでヘルスチェックしているインタフェースを意図的にダウンさせ、スレーブに仮想IPが引き継がれた後にインタフェースをアップさせたとき
⇒フェイルバックする
(3) keepalivedでヘルスチェックしているインタフェースに繋がるLANケーブルを抜いて、スレーブに仮想IPが引き継がれた後にLANケーブルを再接続させたとき
⇒フェイルバックしない
今回の結果より、コマンドにてインタフェースをダウンさせた場合と物理的にLANケーブルを抜いた場合とではkeepalivedの挙動が変化しているため、近々、keepalivedの実装を確認してみようと思います。