CLVMに挑戦(アクティベートフラグ編その4)

前回、2ノードクラスタで片系ダウンした時のLVMの操作問題が解決出来た、かのように見える。
でも実際は、まだ問題を抱えている。

以下の手順を実施してみるとその問題に直面する。

1. 両ノード(gemini/cancer)起動。
2. geminiでファイルシステムマウント。
3. cancerを強制停止。(障害を想定)
4. cancerがダウンしている状態で、geminiを再起動。
5. geminiで必要に応じてファイルシステムマウント。

3番までは前回の作業と同じ。
ただ、実際にはcancerの障害が修復しきれないうちに、geminiをメンテナンスで再起動(4)させないといけない、ということは想定できる。
この時、gemini再起動後に正しくファイルシステムマウントが出来ない(5)と思われる。

実際にやってみよう。
まずは両ノード起動していること。
続いて、gemini側でファイルシステムをマウントする。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ sudo lvchange -an vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2

cancerを強制停止させる。(KVMホストから実施)
(sagittarius) $ virsh destroy cancer
(sagittarius) $ virsh list --all

geminiでディスク状態を確認
(gemini) $ df /mnt/ocfs2
(gemini) $ ls -l /mnt/ocfs2
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs

(メンテナンスを想定して)geminiを再起動
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(gemini) $ sudo shutdown -r now

geminiでファイルシステムを使用する
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
ここでハングしてしまう。

このタイミングでは、geminiで当該ディスクが利用できる状態、というのが理想だが、現実はこのような状態。(cancerを起動させれば、geminiでディスクを利用することが出来る。)
これでは、とても不便だ。

で、このあたりを制御するcorosyncパラメータが、wait_for_allだと考えられる。

とりあえず、復帰させるためにcancerを起動させよう。(KVMホスト側から)
(sagittarius) $ virsh start cancer
(sagittarius) $ virsh list --all

とりあえずgeminiでディスクを使っている状態にする。
(cancer) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2

さて、じゃぁcorosyncのwait_for_allについて確認してみよう。
まずはman。
(gemini) $ man 5 votequorum
これを見てみると、以下のことが分かる。

• デフォルトは0
• two_nodeを1に設定すると、wait_for_allも自動的に1に設定される。
  (ただし、別途0にすることは可能。)
• wait_for_allが1になっている場合、全てのノードが同時に稼働状態にならないと、corosyncが稼動状態にならない。
  (wait_for_allが0の場合は、稼動状態のノード数が、ノード全数の過半数に到達した段階でcorosyncが稼働状態になる。)

2ノードクラスタの場合、2ノードとも稼動状態にならないとサービス開始出来ないようだ。
スプリットブレイン発生時等を考えれば、この仕様は正しいと思うけど、これではちょっと運用し辛い。

今回はHAクラスタではなく、使うリソースは共有ファイルシステムだけなので、「両方のノードで同時にサービスが起動して、ファイルシステムが壊れてしまう」等のトラブルは考えなくていい、はず。

であれば、wait_for_allの機能は不要なので、0に変えてみたらどうだろうか…。
どうせ実験環境なので、試してみよう。
両ノード、とりあえずアンマウントとファイルシステムのディアクティベートを実施。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(cancer) $ sudo lvchange -a n vg-ocfs2/lv-ocfs

/etc/corosync/corosync.confを修正
(gemini) $ sudo vi /etc/corosync/corosync.conf
「quorum{}」の中、「two_node: 1」を追記した下に、「wait_for_all: 0」を追記する。
(cancer) $ sudo vi /etc/corosync/corosync.conf
geminiと同様の変更を施す。

設定読み直し。(これで反映されるのかなぁ？)
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl daemon-reload

上で実施したことを試してみよう。
gemini側でファイルシステムをマウントする。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ sudo lvchange -an vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2

cancerを強制停止させる。(KVMホストから実施)
(sagittarius) $ virsh destroy cancer
(sagittarius) $ virsh list --all

geminiでディスク状態を確認
(gemini) $ df /mnt/ocfs2
(gemini) $ ls -l /mnt/ocfs2
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs

(メンテナンスを想定して)geminiを再起動
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(gemini) $ sudo shutdown -r now

geminiでファイルシステムを使用する
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
先程はここでハングしてしまったが、今回は問題なく見える。
この時点ではアクティベートされているが、これは

• 当該lvolは他のノードは掴んでいない
• OS(gemini)は起動時にこのlvolをアクティベートする

の2つの状態のため。(2番目の件は別途検討予定)

とりあえず、排他モードでアクティベートし直して、普通にI/O出来るか確認。
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2
(gemini) $ ls -l /mnt/ocfs2
内容確認出来るので、適当にI/Oしておこう。

問題無さそう。

2ノードクラスタ＆排他制御が必要の場合は、この実装か？
ただ、auto_tie_breakerとauto_tie_breaker_nodeというパラメータも気になる。
調べておきたいけど、後回しでいいかなぁ？

後回しにして、アクティベートフラグのs(-asy/-asn)を実験しよう。