というわけでgemini/cancerのクラスタ修正

前回判明した内容を、gemini/cancerのクラスタに適用してみる。

その前にまず、状態確認をしておく。
sudo pcs status
クラスタとリソースが起動している状態であること。

sudo corosync-quorumtool -s
Flags: が Quorate LastManStanding AutoTieBreaker になっている。
＃2Nodeがない。

ls /etc/dlm/dlm.conf
カスタマイズされたファイルが存在しているはず。

cat /etc/corosync/corosync.conf
quorum{} の中に

• auto_tie_breaker: 1
• last_man_standing: 1
• two_node: 1
• wait_for_all :0

が記載されている。

まずは、dlm.conf だが、すでに dlm-clone リソースが動いているので、それを止めてしまう。
sudo pcs resource disable dlm-clone
sudo pcs status
dlm-clone が止まることで、それに引きずられて他のリソースも停止したはずだ。

(gemini/cancer) $ sudo rm /etc/dlm/dlm.conf
(gemini/cancer) $ sudo ls /etc/dlm/dlm.conf
ファイルが無くなったはずだ。

この状態で、リソースを復旧させる。
sudo pcs resource enable dlm-clone
sudo pcs status
数秒でリソースが起動してくるはず。

続いて、corosync.conf を修正する。
ここでは gemini で実施。
(gemini) $ sudo vi /etc/corosync/corosync.conf
auto_tie_breaker と last_man_standing の2行を削除し、two_node: 1 と wait_for_all: 0 の2行を残す。(provider 行も残す)

そしたら、corosync.conf を再読込する。
(gemini) $ sudo pcs cluster reload corosync
(gemini) $ sudo pcs cluster sync
(gemini) $ sudo corosync-quorumtool -s
あれ？ダメだ。

となると、corosyncを再起動かなぁ？
(gemini) $ sudo systemctl restart corosync
(gemini) $ sudo pcs status
リソースが再起動するのを待つ。
(cancer) $ sudo systemctl restart corosync
(cancer) $ sudo pcs status
リソースが再起動するのを待つ。

(gemini/cancer) $ sudo corosync-quorumtool -s
Flags: が 2Node Quorate になったのが確認できる。
更に、Quorum: が 2 だったものが 1 になった。
これで、片系ダウンした時の挙動が安定するはずだ。

gemini/cancer は仮想マシンなので、ホスト側で片方ずつ落としながら、生き残った方のノードで
sudo pcs status
sudo corosync-quorumtool -s
を実行したり、片方落ちている状態で、生き残っている方のノードを再起動させてみよう。
問題なく稼働するはずだ。
ってあれー？やっぱりdlmがクラッシュしたー。gemini/cancerを再起動させたら、少しはマシになった。
う～ん。1604のdlmだと不安定なのかなぁ。

試しに、gemini/cancerを1804にアップグレードして、同じようにクラッシュテストをしてみたが…。
dlmがクラッシュする事象が発生しない…。これは…1604のdlm(4.0.4)と、1804のdlm(4.0.7)の差か…？changelog見てみても、それっぽい記述は無いが…。

ということで、結論としては1804を使え、ということか。
ホスト側である sagittarius/aquarius はいずれも1604。
gfs2を使用しているがpacemaker管理になっていない。
今後は

• sagittarius/aquariusにpacemakerを導入し、gfs2をpacemaker管理下に置く
• 1604→1804のアップグレードを行う

という流れで、sagittarius/aquariusをメンテナンスしよう。
バックアップ取るのを忘れないようにしないとね。