2019年5月5日日曜日

2ノードクラスタでの特殊運用やっと分かった!

https://uramocha02.blogspot.com/2019/05/1604gfs2pacemaker.html
ココで書いたけど、2ノードクラスタは半分諦めていた。
もう一度書くと
2ノードクラスタ
片方のノードが死亡
生きている方のノードをメンテナンスで再起動
させると、生きている方のノードでもクラスタが正常起動しない、という問題だ。

これ、過半数のquorumに到達しない(2ノードなので、1ノードしか生きていなければ50%、つまり過半数に到達していない)というのが直接の原因。

で、クラスタによってはquorum diskという特殊な共有ディスクを用意して、そのquorum diskのロックに成功したノードは、quorumを1つ余分に得る、という仕組みを用意している。
これによって、生き残っているノードは、自身のquorum+quorum diskをロックすることによって得られるquorumの合計2つのquorumを得て、過半数に到達する、という作りだ。

で、RHEL6時代のpacemakerには、そのものズバリのquorum disk(qdiskd)というソフトがあり、これを利用することで1ノードでも暫定運用が可能、という動きになる。

Ubuntu16.04にはこのquorum diskが無く、またUbuntu18.04やRHEL7は、quorum diskではなく、quorum deviceというのが使えるのだが、こちらはクラスタとは別に1つマシンが必要。
ということで、2ノードクラスタなのに3台のマシンが必要ということで、正直諦めていた。

諦めつつ、18.04のクラスタの構築を始めていたのだが、corosyncのコマンドにcorosync-quorumtoolというのがあるのに気づいた。
もしかしてコレ…と調べてみたら、ノードが持つquorum数を、意図的に変更することができるようだ。
だったら、生き残っている方のノードのquorum数を、1ではなく2にしてみたら、quorum数が過半数に到達し、1ノードでもクラスタ動くんじゃないか?ということで急遽実験。

結論は成功。

生き残っている方のノードで
sudo corosync-quorumtool -s
を実行し、自身のノードIDを確認する。
続いて
sudo corosync-quorumtool -v 2 -n (先程確認したノードID)
と実行し、指定したノードが持つquorum数を2つにすることで、クラスタが稼働し始めた。
なるほど…こういうことか…。

注意事項としては、OS再起動させるとquorum数も元に戻ってしまうので、再起動のたびにquorum数を再設定する必要がある、という点だ。
quorum数を固定することもできるかもしれないが、死んだノードを復旧させた後、またquorum数を1に戻す必要があるので、固定する機能は多分無いだろう。

やー、ここまで辿り着くの、永かった…。

0 件のコメント:

コメントを投稿