dlmのフェンシング(その1)

前回の最後にちらっと書いた「dlm/corosync のフェンシング」について、だ。
今後の予定にも書いていた内容だが、gemini / cancer の両系統のウチ、片方が障害で停止すると、しばらくしたらディスクI/Oに問題が起きる。(ハングしたような状態になる。)

これを解決しないことには、常用するにはちょっと厳しい。

で、それのキーワードになりそうなのが「dlmのフェンシング」だ。
詳細はちょっと異なるが、イメージ的には「障害があったノード(サーバ)をクラスタから切り離す」というようなモノになる。
＃今まで放置していたのは、他にも問題がたくさんあって、一つ一つ潰していくウチに、この問題を放置してたような状態になった、というだけで他意は無い。

まぁとりあえず今回は、現象の再現をさせてみるところからだ。

gemini / cancer を停止させるので、gemini / cancer 上で仮想マシンが動いていたら停止させておいてくれ。

ココからは、teraterm を2つ開いて、それぞれ gemini にログインしておこう。
それぞれのセッションを geminiA / geminiB と表記しておく。

まずは geminiA で共有ディスクの中身が読めることを確認しよう。
(geminiA) $ ls -l /etc/libvirt
(geminiA) $ ls -l /var/lib/libvirt

確認できたら、キャッシュをクリアしておく。
(geminiA) $ sudo bash -c "sync;sync;sync"
(geminiA) $ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"

そうしたら、cancer を停止させる。
この時、cancer を正常終了させるのではなく、(障害が発生したと想定して)強制的に停止させる。
停止は、cancer が動いているホストOS(sagittarius)から実行だ。
(sagittarius) $ date ; virsh destroy cancer

cancer が停止したら、もう一度 gemini で確認をする。
(geminiA) $ ls -l /etc/libvirt
どうだろう？応答が帰ってこなくなったんじゃないかな？
Ctrl+Cでも応答が無く、対応しようがなくなるはずだ。

復旧させるためには、geminiB の方で以下のコマンドを実行する。
(geminiB) $ ps -ef | grep dlm_controld | grep -v grep
原因は掴めていないのだが、dlm_controld が生きている時と、死んでいる時の2パターンが発生している。

dlm_controld が生きている時は、以下のコマンドで復旧出来る。
(geminiB) $ dlm_tool ls
ノードIDが出て来るので、cancer に相当する方のノードIDを確認する。
(デフォルトでは、IPアドレスから自動生成されているので、cancer の方が大きな数字になっているはずだ。)

確認したノードIDを引数に、以下のコマンドを実行する。(下線部をノードIDに指定する)
(geminiB) $ sudo dlm_tool fence_ack 1084766089
(geminiB) $ dlm_tool ls

これで復旧したはずだ。geminiA のコンソールも戻ってきていると思う。

dlm_controld が死んでいる時は、色々調査したが復旧させることが出来なかった。
そのため、ホスト側から強制的に再起動させるしかない。
(sagittarius) $ virsh reset gemini

また、強制的に停止させてしまった cancer も起動しておこう。
(sagittarius) $ virsh start cancer

今回はココまでにしよう。