リソースが起動しない

16.04 から 18.04 へのバージョンアップは実施できたけど、pacemaker のリソースが起動しない。
stonith は起動しているようなんだけど、リソースが起動しなきゃクラスタにならないじゃん。

で、corosync.log を見てみると、どうも stonith(fence_scsi) でエラー出している様子。
pcs status だと起動しているように見えるので、問題無いかと思っていたんだけど、もともと 16.04 時代の設定も誤っていたんじゃないか？で、偶然上手く動いていた、と。

というわけで、stonith(fence_scsi) の設定を見直してみる。

そもそも、pcmk_host_list って必要なのか？

$ sudo pcs stonith update scsi-fence pcmk_host_list=
$ sudo pcs stonith show scsi-fence
$ sudo pcs status --full

ダメだ。

nodenameは？

$ sudo pcs stonith update scsi-fence nodename=
$ sudo pcs stonith show scsi-fence
$ sudo pcs status --full

上がってきた…。

どうやら、fence_scsi で全ノードを管理する場合は、pcmk_host_list も nodename も未設定で良かったらしい…。
オプションパラメータをきちんとチェックしないとアカンなぁ…。

この後分かったんだが、pcmk_host_list は設定していないとアカンらしい。
ん…？もしかして pcmk って pacemaker のことか？
というわけで再設定する。

$ sudo pcs stonith show scsi-fence
$ sudo pcs stonith update scsi-fence pcmk_host_list="sagittarius aquarius"
$ sudo pcs stonith show scsi-fence

あと、corosync.log を見ていたら、 Startup probes: disabled (dangerous) という記載があった。以前、enable-startup-probes を false に設定していたが、これも誤りのようだ。
元に戻しておこう。

$ sudo pcs property set enable-startup-probes=
$ sudo pcs property show --all | grep enable-startup-probes

stonith 関連の設定が問題だったので、幾つかテストしてみる。
まずは普通にクラスタの起動停止

$ sudo pcs cluster stop --all
$ sudo pcs cluster start --all
$ sudo pcs status --full

問題なしだ。

続いて、片方のノードのクラスタ停止起動

(sagittarius) $ sudo pcs cluster stop aquarius
(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs cluster start aquarius
(sagittarius) $ sudo pcs status --full

問題なし。

(aquarius) $ sudo pcs cluster stop sagittarius
(aquarius) $ sudo pcs status --full
(aquarius) $ sudo pcs cluster start sagittarius
(aquarius) $ sudo pcs status --full

問題無いようだ。

今度は、ノード自体の再起動だ。
その前に、以前設定した tmpfiles の設定を削除してみよう。fence_scsi の設定が誤っていたことが原因なのかもしれないので。

$ cat /etc/tmpfiles.d/var-run.conf
$ sudo rm /etc/tmpfiles.d/var-run.conf
(aquarius) $ sudo systemctl reboot
(sagittarius) $ sudo pcs status --full

おっといけない。まだクラスタの自動起動を設定していないんだった。
手で起動する。

(aquarius) $ sudo pcs cluster start aquarius
(sagittarius) $ sudo pcs status --full

問題なさげだ。(tmpfiles の /var/run/cluster も自動生成されてる)

さて…次は鬼門。vm-leo が稼働したままの sagittarius を再起動させるパターンだ。

(sagittarius) $ sudo systemctl reboot
(aquarius) $ sudo pcs status --full

やっぱり、sagittarius の停止に詰まる症状が出る。
sagittarius のコンソールを見ている限り、vm-leo が停止し切る前にその他のリソースが停止しようとしてエラーとなり、それが原因で libvirt や iscsi-initiater の停止が上手く行かず、強制停止が完了するまでリブートしない、という状態のようだ。
この辺りは、リソース停止のタイムアウト値を設定したりすれば解決しそうだ。
ただ、これまではこの症状が起きると、aquarius 側の dlm もハングしてしまい、aquarius も再起動させないと復旧しなかった。
今回は、aquarius は正常稼働している。この辺りが、fence_scsi の設定を見直した結果か。

(sagittarius) $ sudo pcs cluster start sagittarius

う～ん。なんとか起動してきたな。
vm-leo が停止するのに必要なタイムアウト設定は別途調べることにしよう。
vm-leo はオンラインマイグレーションさせる方法も調べて実装しておきたいし。

続いて、フェンシングとアンフェンシングのテストをやってみる。
sagittarius から aquarius をフェンシング

(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs stonith fence aquarius
(sagittarius) $ sudo pcs status --full

クラスタから aquarius が切り離され、aquarius 上の pacemaker プロセスがダウンした。ん？ corosync は起動しているぞ…？
この時点で気になるのは、stonith(scsi-fence) が sagittarius 上で動いていない、という点。aquarius をシャットダウンさせた時は、scsi-fence は sagittarius 上で動き出したのだが…。
一旦、aquarius 上の corosync を止めてみるか…。

(aquarius) $ sudo systemctl stop corosync
(sagittarius) $ sudo pcs status

あー、aquarius 上の corosync を停止させたら、scsi-fence が sagittarius 上で動き出した。そーゆーことか。
一旦この状態で、sagittarius を再起動させてみたい。一応、クラスタは正常終了させてからね。

(sagittarius) $ sudo pcs cluster stop sagittarius --force
(sagittarius) $ sudo systemctl reboot

リブートしてきたら、クラスタが( sgaittarius 単独で)起動するか確認だ。

(sagittarius) $ sudo pcs cluster start sagittarius
(sagittarius) $ sudo pcs status

sagittarius 上で起動してきたな。

fence された aquarius は、プロセスが中途半端の状態のはずなので、きっちり再起動させておこう。

(aquarius) $ sudo systemctl reboot

むぅ。停止処理に時間がかかってるな…。fence されたことで、プロセス状態が半端な状態になっているのが原因か。
いや、どうやら停止処理がハングしたようだ…。一旦強制的に(物理的に)電源Off/ONしよう。
pacemaker プロセスを systemctl で停止させたのが問題だったのかもしれない。
aquarius が起動してきたらクラスタを起動させ、もう一度同じことを実施してみる。

(aquarius) $ sudo pcs cluster start aquarius
$ sudo pcs status
(sagittarius) $ sudo pcs status --full
(sagittarius) $ sudo pcs stonith fence aquarius
(sagittarius) $ sudo pcs status --full

aquarius からクラスタの停止は…？

(aquarius) $ sudo pcs cluster stop aquarius

う～ん…。それっぽい動きはしたが、dlm プロセスが中途半端だ…。
クラスタ起動は…？

(aquarius) $ sudo pcs cluster start aquarius

ダメだな…。
イマイチ対応方法が良くわからない。リブートさせて復旧させるけど、--force のオプションをつけよう。

(aquarius) $ sudo systemctl reboot --force

かなり時間はかかるが起動してくるはずだ。
再びクラスタに組み入れておこう。

(aquarius) $ sudo pcs cluster start aquarius

fence されたノードは、再起動させないと復旧出来ないような記載を何処かで見かけたので、--force で再起動させるしかないか。オプションつけ忘れると、再起動がハングするという最悪の自体になるので、何か他に方法はありそうだが…。

よく考えてみたら、stonith の説明は主に UPS や IPMI による強制停止・強制再起動が中心だ。ってことは、fence 発生時は相手方は強制的に電源が落ちる(or再起動する)ことが前提になっていて、今回採用しているような fence_scsi はある意味例外なのかもしれない。
であれば、再起動に手間がかかるのは、例外として受け入れるしか無いのかな？

まぁ、当初の目的であった「リソースが起動しない」という問題は解決したから、これでヨシとするか。