リソースが起動しない

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 はある意味例外なのかもしれない。
であれば、再起動に手間がかかるのは、例外として受け入れるしか無いのかな？

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

16.04から18.04へバージョンアップ(sagittarius)

aquarius のバージョンアップも何とか終わり、続いて sagittarius のバージョンアップを行う。
流れは基本的に aquarius で実施した手順と同じだ。
バックアップまでは前回実施済みなので、クラスタ停止とクラスタの自動起動停止からだ。

$ sudo pcs cluster stop sagittarius --force
$ sudo pcs cluster disable sagittarius

そしたらバージョンアップ実施。これはコンソールから実施しよう。

$ sudo LANG=C do-relase-upgrade

出てくるメッセージや、設定ファイルの更新の情報は、aquarius の時と同じはずだ。
同じように対応しよう。

あれ？何故か Postfix Configuration の画面が出てきた。
選択肢としては

No configuration
Internet Site
Internet with smarthost
Satellite system
Local only

となっていて、デフォルトでは Internet Site にフォーカスが当たってる。
Postfix なんて設定したかな…？まぁ、No configuration にしておくか。必要なら別途セットアップすりゃいい。

バージョンアップと再起動が終わったら、設定の確認と反映だ。

$ sudo systemctl status
$ sudo systemctl --state=failed

/etc/lvm/lvm.conf は、直接編集するのではなく、コマンドで編集しよう。

$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf
$ sudo lvmconf --enable-cluster
$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf

/etc/ssh/sshd_config は直接編集する。

$ sudo vi /etc/ssh/sshd_config

-----
PasswordAuthentication が含まれている行(コメントになっているはずだ)を探し、その下に以下の行を追加する。
PasswordAuthentication no
最後に以下の行を追加する。
Match Address 192.168.55.0/24
        PasswordAuthentication yes
Match Address 127.0.0.0/8
        PasswordAuthentication yes
-----

/etc/default/libvirt-guests も直接編集だ。

$ sudo vi /etc/default/libvirt-guests

-----
ON_SHUTDOWN の行を探して、以下のように書き換える。(追加する)
ON_SHUTDOWN=shutdown
-----

systemd の unit 定義も。

$ sudo EDITOR=vi systemctl edit ovsdb-server.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

$ sudo EDITOR=vi systemctl edit ovs-vswitchd.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

再読込。

$ sudo systemctl daemon-reload
$ sudo systemctl list-dependencies --before ovsdb-server.service
$ sudo systemctl list-dependencies --before ovs-vswitchd.service

fstab も直しておこう。

$ sudo vi /etc/fstab

-----
バックアップボリュームをマウントする行のオプションに
vers=1.0
を追加する
-----

他にも、/etc/fstab エントリや、 /etc/auto.master.d/ とかで cifs マウント設定が入っているところがある。vers=1.0 を追加しておこう。

No longer supported になっているパッケージを削除して再起動だ。

$ sudo apt-get remove gcc-5-base gcc-6-base tcpd

う～む。postfix が起動に失敗するなぁ。そもそも、aquarius には導入していない。どこで導入されたんだろうか…？
使ってないから削除しておこう。必要ならまた入れればいいからね。

$ sudo apt-get --simulate remove postfix
$ sudo apt-get remove postfix
$ sudo apt autoremove

再起動して、systemd が正しく動いているようなら、バックアップ取っておしまい。

次回以降、クラスタ再設定を行う。

あぁそうそう、18.04 の標準のネットワークは netplan になっている。
今回は 16.04 からそのまま引き継いで ifupdown にしていて、netplan には切り替えていない。
OpenvSwitch が netplan には対応していないようなので、そのまま ifupdown にしている。
もし、18.04 を素でインストールしたのなら、 netplan を削除して ifupdown を導入しないと駄目なので要注意。

16.04から18.04へバージョンアップ(aquarius)

さて、色々検証が中途半端になってしまったが、いい加減18.04にバージョンアップしよう。

過去に一度、sagittarius をバージョンアップしたが、別の問題が出てリストアしている。
今回はそのリベンジだ。

まずは慎重に、両サーバのパッチ適用(16.04の最新版)を行う。
aquarius から実行する。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster disable aquarius
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot
$ sudo pcs cluster enable aquarius
$ sudo pcs cluster start aquarius
$ sudo fence_scsi -o on -n aquarius -d /dev/mapper/fence-device

続いて sagittarius から実行。

$ sudo pcs cluster stop sagittarius
$ sudo pcs cluster disable sagittarius
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot
$ sudo pcs cluster enable sagittarius
$ sudo pcs cluster start sagittarius
$ sudo fence_scsi -o on -n sagittarius -d /dev/mapper/fence-device

両方のノードをバックアップしておこう。
バックアップスクリプトは今まで使用していたもので OK だ。

バックアップが終わったら、いよいよバージョンアップだ。
バージョンアップはコンソールから実行しよう。
aquarius から。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster disable aquarius
$ LANG=C sudo do-release-upgrade

途中、No longer supported として gcc-5-base gcc-6-base tcpd の3つがリストアップされた。まぁ不要なので、あとで削除しておけばいいか。
設定ファイル類の反映で、幾つかが「カスタマイズされているけど、ディストリビューター版を入れるか？今使っているものをそのまま使うか？」という選択肢が出てくる。

/etc/default/libvirt-guests
過去に有効にした ON_SHUTDOWN=shutdown が無効になる。
こちらは、ディストリビューター版を採用して、後で書き換えよう。

/etc/ssh/sshd_config
差分が多いが、外からログインする時の設定以外はディストリビューター版で良さそうだ。
後から、

PasswordAuthentication no
Match Address 192.68.55.0/24
 PasswordAuthentication yes
Match Address 127.0.0.0/8
 PasswordAuthentication yes

を書き加えることにする。

/etc/apt/apt.conf.d/50unattended-upgrades
こちらは、カーネル類を自動アップデートしないように明示的に指定している。
これ、多分ディストリビューター版をそのまま採用して問題無いだろう。
ちなみに、Unattended-Upgrade::Package-Blacklist { } に

"linux-headers-generic";
"linux-signed-generic";
"linux-signed-image-generic";

を足し込んでいる。

/etc/lvm/lvm.conf
こちらは、クラスタlvmを使用するために

locking_type = 3
use_lvmetad = 0

を指定しているが、ディストリビューター版を導入し、後から修正することにする。

無事にアップグレードが済み、リブートされたら、検証と設定の戻しを行おう。

$ sudo systemctl status
$ sudo systemctl --state=failed

lvm2-pvscan が一部失敗しているが、多分これは /etc/lvm/lvm.conf を修正すれば正しくなるはず。
設定ファイルを修正するのは以下の3ファイル
/etc/default/libvirt-guests
/etc/ssh/sshd_config
/etc/lvm/lvm.conf

/etc/lvm/lvm.conf は、直接編集するのではなく、コマンドで編集しよう。

$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf
$ sudo lvmconf --enable-cluster
$ grep -e locking_type -e use_lvmetad /etc/lvm/lvm.conf

/etc/ssh/sshd_config は直接編集する。

$ sudo vi /etc/ssh/sshd_config

-----
PasswordAuthentication が含まれている行(コメントになっているはずだ)を探し、その下に以下の行を追加する。
PasswordAuthentication no
最後に以下の行を追加する。
Match Address 192.168.55.0/24
        PasswordAuthentication yes
Match Address 127.0.0.0/8
        PasswordAuthentication yes
-----

/etc/default/libvirt-guests も直接編集だ。

$ sudo vi /etc/default/libvirt-guests

-----
ON_SHUTDOWN の行を探して、以下のように書き換える。(追加する)
ON_SHUTDOWN=shutdown
-----

ここまで編集したら、再起動しよう。

$ sudo systemctl reboot

あれ？リブートしたら、ネットワークの起動が上手く行かなかった。

$ sudo ifdown extsw
$ sudo ifup extsw

通信はできるな…。もう一度再起動してみる。

$ sudo systemctl reboot

やっぱり駄目だ。

見てみると、networking.service 起動時に、/var/run/openvswitch/db.sock が無い、というエラーになっている。
どうやら、ifupdown で使用する interface 定義、OpenvSwitch 関連のところが誤っていたようだ。(誤っていたのか、仕様が変わったのかは良くわからないが…)

ちょっと原因が違ったので、ここから先は全面書き換え。

ココを見ると、systemd の unit 定義が間違っているようだ。
なので、それの対応を行う。

$ sudo EDITOR=vi systemctl edit ovsdb-server.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

$ sudo EDITOR=vi systemctl edit ovs-vswitchd.service

-----
以下のように作成
[Unit]
Before=networking.service
-----

再読込。

$ sudo systemctl daemon-reload
$ sudo systemctl list-dependencies --before ovsdb-server.service
$ sudo systemctl list-dependencies --before ovs-vswitchd.service

全面書き換えココまで

これで再起動したら、問題なく上がってくるはずだ。

ここで、クラスタへの組み直しをやってみたいところだが、corosync のバージョンが異なる機器間でクラスタを組もうとすると、内部DB(cib) のフォーマットが違うためか、マトモに動かない。
それどころか、syslog や corosync.log に大量にログが吐き出され、 /var/log がパンクしてしまうという事象が発生する。
そのため、クラスタ組み直しは、sagittarius のバージョンアップが終わってからにしよう。

最後に、No longer supported になっている3つのパッケージを削除しておこう。

$ sudo apt-get remove gcc-5-base gcc-6-base tcpd

とりあえずこれで、18.04へのバージョンアップは完了かな？
おっと、せっかく18.04へのバージョンアップが出来たので、バックアップを取っておくのを忘れないように。
だけど、18.04 にしてから CIFS へのアクセスが異常に遅くなった。
バックアップするのもシャレにならないほどの遅さだ。どうやら、cifsのデフォルトが変わったことによるものらしい。
aquarius はバックアップボリュームのマウントを、fstab で指定しているので、それを修正しよう。

$ sudo vi /etc/fstab

-----
バックアップボリュームをマウントする行のオプションに
vers=1.0
を追加する
-----

これで大丈夫なはず。

ちょっと長くなってしまったので、sagittarius のバージョンアップは次回。

ノード再起動で dlm がハング(他にも問題発生、一旦停止)

さて、次はノード再起動で dlm がハングするという現象の調査だ。

状況としては、vm-leo が稼働しているノードの OS を再起動すると、dlm がエラーを吐いて再起動が止まる、という状態だ。
調査していく過程で、何度か電源 Off/On を行うことになるので、コンソール前で実施しよう。また、強制停止を行う関係で、OS が壊れる可能性がある。sagittarius / aquarius の両方ともバックアップを取っておくこと。

では再現テストからだ。
vm-leo は sagittarius で動いている前提で進めていく。

最初は、vm-leo が動いていない方、aquarius を再起動してみる。

(aquarius) $ sudo systemctl reboot

特に vm-leo の稼働、sagittarius の稼働に影響は無かったはずだ。

aquarius が起動したら、fence_scsi の登録はしておこう。

(aquarius) $ sudo fence_scsi -o on -n aquarius -d /dev/mapper/fence-device
$ sudo pcs stonith cleanup

今度は sagittarius を再起動させてみよう。
この段階でハングしてしまうはずだ。PC のコンソールを使って実行したほうがいいだろう。

(sagittarius) $ sudo systemctl reboot

停止処理でハングするはず。

で、sagittarius がハングしている状態で aquarius 側からクラスタの状態を確認してみる。

(aquarius) $ sudo pcs status --full

vm-leo や pool-default の停止に失敗しているだろう。
暫く放置していると、aquarius 側でも dlm が異常をきたす。
こうなるともう、2台とも強制再起動(物理的にリセットスイッチを押す)しかなくなる。
これじゃ、HAクラスタとしては意味が無い。

2台とも強制再起動させて、クラスタを正常稼働させておこう。

(sagittarius) $ sudo fence_scsi -o on -n sagittarius -d /dev/mapper/fence-device
(aquarius) $ sudo fence_scsi -o on -n aquarius -d /dev/mapper/fence-device
$ sudo pcs stonith cleanup
$ sudo pcs status --full

今回、この現象を調査していたら、それとは別の問題を発見した。
2ノードクラスタなのだが、片方(例えば aquarius )がダウンしている状態で、生き残っている方( sagittarius )のクラスタを停止、起動すると、クォーラムは得られているにも関わらず、リソースが何も起動してこない、という状態だ。
片方のノードが故障で停止していても、生き残っている方で稼働・メンテナンス等は有り得る話なので、シングルノード状態でリソースが起動しないのは致命的だ。

ここまでボロボロと問題が出てくるのは、もしかしたら自分の実装手順がおかしいのではなく、Ubuntu16.04 の pacemaker にまだまだバグが含まれているのではないか？とまで疑うようになってきた。
本当は、これらの問題を 16.04 上で解決してから、18.04 にバージョンアップしようと思っていたのだが、18.04 のバージョンで解消している可能性もある。

中途半端になってしまったが、一旦 pacemaker 化の検証は止めて、18.04 にバージョンアップしていくことにする。

fence_scsi がコケる

リソースの再起動問題は解決したと思ったんだけど、次の作業である「ノード再起動で dlm がハング」を調査しようとしたら…クラスタ起動時に fence_scsi(scsi-fenceデバイス)がコケる、という事象が発生した。

調べて行ったら、前回行った作業( sudo pcs property set enable-startup-probes=false )で、scsi-fence デバイスの.keyファイル等が自動作成されなくなった、というのが原因。

一度試してみると分かる。

$ sudo pcs status

vm-leo が aquarius で稼働していないことを確認。
続いて、aquarius のクラスタを再起動させる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

この状態では、問題なく aquarius がクラスタ参加するはずだ。
では、aquarius を OSごと再起動させてみよう。

$ sudo pcs cluster stop aquarius
(aquarius) $ sudo systemctl reboot

リブート後…

$ sudo pcs status

scsi-fence デバイスが aquarius 上で起動失敗、sagittarius で起動しているはずだ。
これは、/var/run/cluster にあるはずの fence_scsi.dev と fence_scsi.key ファイルが再作成されていないことが原因。
今まではクラスタ起動時に自動的に作成されていたようだから、問題なかった。
とりあえずこのままではよろしく無いので、再作成しておこう。

(aquarius) $ sudo fence_scsi -n aquarius -d /dev/mapper/fence-device  -o on

これで、/var/run/cluster にファイルが作成されたはずだ。

ただ、クラスタ上は aquarius 上で scsi-fence の起動に失敗した、という情報が残っているので、それもクリアしておこう。

$ sudo pcs stonith cleanup scsi-fence

これで一旦復旧。

さて、原因と対策なんだけど…。
調べたけどさっぱり分からない。ただなんとなく、Ubuntu18.04にバージョンアップしたら解決してる気がする。
なので、この先18.04にバージョンアップしてから再確認しよう。
それまでは、上に記載した暫定対処で回避することにする。

リソースが勝手に再起動する

謎な挙動が2つ見つかっているが、そのうち1つが「vm-leo が稼働してない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう」というものだ。

vm-leo が sagittarius で稼働している状態で、leo にログインしたセッションを作り、sagittairus/aquarius のいずれかで以下のコマンドを実行するとわかる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

で、どのタイミングで vm-leo が再起動するのかを調べるために、以下のように設定した。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

つまり、aquarius では、vm-leo 以外のすべてのリソースの自動起動を停止した。
(vm-leo 自体は、前提となる pool-default-clone が起動しないと起動しないし、そもそも sagittarius 上で起動しているので、aquarius が起動しても影響ないはずなのだが…)

その状態で、まず aquarius のクラスタの停止・起動を実行する。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

なんと、aquarius のクラスタ起動だけで、vm-leo が再起動してしまう。

ということは、クラスタパラメータが関係しているということだ。

$ sudo pcs property show --all

それっぽいパラメータは、enable-startup-probes か。
デフォルト値は true なので、 false に設定してみよう。

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

これで aquarius のクラスタ停止・起動を実行してみる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

vm-leo は再起動しなかったと思う。

続いて、リソースを一つずつ許可してみよう。
まずは dlm-clone

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY

大丈夫のようだ。
次は clvmd-clone

$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

ここで vm-leo が再起動してしまう。
更に先を確認するために、vm-leo が復帰したら、shared-pool-clone も確認しておこう。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

ここでも vm-leo が再起動してしまう。
最後に、pool-default-clone だ。vm-leo が復帰してから試してみよう。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

ここでは vm-leo の再起動は発生しない。

vm-leo の基盤となるリソースのうち、clvmd-clone と shared-pool-clone のリソースが起動すると、vm-leo が再起動する。

corosync.log をチェックしてみたら、clvmd-clone が起動すると、なぜか pool-default-clone と vm-leo が restart していた。
clvmd-clone と pool-default-clone の間には、shared-pool-clone が入っているが、そちらは restart になっていない。
う～ん。ということは、clone リソースに何か違いが？
と調べてみたら、いくつか違いがあった。

• dlm-clone
• interleave=true
• ordered=true
• clvmd-clone
• interleave=true
• ordered=true
• shared-pool-clone
• interleave=true
• ordered=(未設定:false)
• pool-default-clone
• interleave=(未設定:false)
• ordered=(未設定:false)

コレ、clone リソース固有のパラメータのようだ。
っていうか、interleave パラメータが関係あるんじゃないか？
というわけで設定してみよう。

$ sudo pcs resource update pool-default-clone meta interleave=true
$ sudo pcs resource show pool-default-clone

そしてもう一度テスト。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY
$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

先程はここで vm-leo が再起動してしまったが、今回は大丈夫のようだ。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

今回、ここでも大丈夫のようだ。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

こちらは問題なし。

というわけで、interleave=true の設定が必要だった。
振り返って過去の設定を見てみたら、ちゃんと interleave=true の設定を入れていた。
ちゃんと設定項目の意味を理解してれば、こんなに悩まなかったのに…。

リソースが勝手に再起動する問題はこれで解決かな？

仮想マシンのクラスタリソース化その2

とりあえず vm-leo が動くところまで行った。
今度はこのリソースを細かく設定する。

まず、リソースの実行順。
vm-leo 自体は、default プールを使用している。そのため、vm-leo の起動の前提条件として、 default プールの有効化、つまり pool-default-clone を前提にする必要がありそうだ。
それを設定する。

$ sudo pcs constraint order start shared-pool-clone then vm-leo

続いて、リソースの実行条件。
当然、shared-pool の起動に成功したノードと同じノードでないと、vm-leo を動かすわけにはいかない。
その制約をつける。

$ sudo pcs constraint colocation add vm-leo with shared-pool-clone

このままでもいいんだけど、何故かいつも aquarius から起動しようとしてしまう。
gemini/cancer でクラスタ組んで、簡単なリソーステストを行っていた時も、 gemini をプライマリノードにしたいのに、なぜか cancer から起動しようとしてた。
多分、ノード名のアルファベット順で若い方を優先してしまうのではないか？と思っている。
で、vm-leo は sagittarius をプライマリノード、aquarius をスレーブノードとして定義したい。
(sagittarius に問題が無ければ sagittarius で起動、問題がある場合は aquarius で起動、みたいな)
以下のように実行する。

$ sudo pcs resource cleanup vm-leo
$ sudo pcs constraint location vm-leo prefers sagittarius=100 aquarius=50
$ sudo pcs resource enable vm-leo
$ sudo pcs status

どうだろう？ vm-leo は sagittarius で起動してきたのではないだろうか？

今回は一旦ココまでにするが、まだ問題が2つ残っている。

1. vm-leo が稼働していない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう
2. vm-leo が稼働しているノードを再起動しようとすると、dlm がハングしてしまう

の2点だ。
ちょっと調べたがまだ解決していない。
解決できるか分からないが、次回からちょっと調査をする。

仮想マシンのクラスタリソース化その1

これまでの作業で、 gfs2 を pacemaker で運用する方法が固まった。

で、 pacemaker を調べていく過程で、リソースエージェントに ocf:redhat:vm.sh と ocf:heartbeat:VirtualDomain の2つが存在することに気付いた。
これ、KVM等の仮想マシンをリソース化するものっぽい。
ってことは、pcs コマンドで仮想マシンを起動停止させたり、sagittarius から aquarius へのマイグレーションが出来たりするのかもしれない。

pacemaker化 の最後に、これを試してみたい。
リソースエージェントに redhat版と heartbeat版 があるのだが、これまでずっと heratbeat版 を使っていたので、今回も heartbeat版 で進めてみる。

まずは設定内容の確認

$ sudo pcs resource describe ocf:heartbeat:VirtualDomain

必須パラメータは config だけだけど、libvirt自体は様々なハイパーバイザに対応しているので、qemu/kvm用のハイパーバイザを指定する必要はある。
それ以外はとりあえずデフォルトのままで作ってみよう。仮想マシンは leo でいいかな？

$ sudo pcs resource create vm-leo \
 ocf:heartbeat:VirtualDomain \
 config="/etc/libvirt/qemu/leo.xml" \
 hypervisor="qemu:///system" \
 meta op start timeout="120s"
$ sudo pcs status

おっと！？いきなりコケてるぞ？いや、ちょっと待ってから再確認すると、vm-leo を aquarius で起動しようとして失敗し、sagittarius で起動成功、という流れのようだ。

いろいろ調査したんだけど、非常にツマらない理由だった。
今回の pacemaker化 の主旨とは全く異なるポイントだったんだけど、メモしておく。

この辺りは、各人の持っているPCのスペックに依るところが大きいので、あくまで参考程度に見てほしい。

それぞれのホストマシンで使っているCPUは以下の通り。

• sagittarius : Intel core i7-6700
• aquarius : Intel core i7-5557U

CPUの世代が1世代違うだけでなく、aquarius の方はノート用の省電力モデルだ。
で、5557UというCPU、Broadwell世代なんだけど、TSXという機能に対応していない。

で、仮想マシン leo の方の仮想CPU定義はと言うと… Broadwell にしている。
仮想マシンのCPU定義が Broadwell の場合、ホスト側のCPUにもTSXという機能が必要なので、5557U というCPU上で動かすことは出来ない。
仮想マシン側の CPU定義を Broadwell-noTSX か、それ以下のモデルにする必要があるようだ。
つまり、今までパワーのある sagtitarius 上で色々検証していたけど、実は aquarius では動かない検証をしていた、ということだ。ナンテコッタイ。

調べてみたら、多くの仮想マシンが仮想CPUを Broadwell と指定してて、ほとんど aquarius では動かせないことが判明。
とりあえず leo だけでも直しておこう。

まずは vm-leoリソースを停止。

$ sudo pcs resource disable vm-leo
$ sudo pcs status
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all

leoが止まっているのを確認しておく。

そしたら、leo の定義変更だ。

(aquarius) $ virsh edit leo
(sagittarius) $ virsh edit leo

---
cpuの <model> の部分を Broadwell から Broadwell-noTSX に書き換える。
---

変更出来たら、まずは各ノードで手作業で上げてみよう。

(aquairus) $ virsh start leo
(aquarius) $ virsh list --all

起動したら leo にログインして、シャットダウンしておこう。

(leo) $ sudo systemctl poweroff

sagittarius でも。

(sagittarius) $ virsh start leo
(sagittarius) $ virsh list --all

起動確認が出来たら leo をシャットダウンしておく。

(leo) $ sudo systemctl poweroff

ココまでが、各人の環境に応じて差が出る部分だ。

leo が両ノードで動かせるのが確認できたら、vm-leoリソースをクリーンナップして起動してみる。

$ sudo pcs resource cleanup vm-leo
$ sudo pcs resource enable vm-leo
$ sudo pcs status

今度は無事に aquarius で動き出した。
aquarius 側で virsh を使ってみると、動いていることがわかるはずだ。

(aquarius) $ virsh list --all

これで vm-leo が動かせるようになったが、まだ設定しておかなければならない項目がある。
起動条件、起動順と起動ノードの優先順、マイグレーション設定だ。
ちょっと長くなってしまったので、これは次回に回す。
っとその前に、vm-leo を停止させて、自動的に上がってこないように抑えておこう。

$ sudo pcs resource disable vm-leo
$ sudo pcs status

systemd設定見直し

随分前の話になるが、初めて dlm/clvmd/gfs2 と openvswitch を導入した時、OSの起動停止が上手く行かず、原因を systemd の起動順や起動速度だと思って、 systemd の各 unit ファイルをいじった。

ここまでの作業で、 corosync.conf の設定内容が pacemaker によって大幅に変更されたり、 dlm を systemd 起動ではなく pacemaker から起動するように変更された。
もしかしたら、これまで問題としていた内容は、これによって解消しているのでは？ということで、 systemd の設定を元に戻してみる。
これまで弄ってきたファイルは、 /etc/systemd/system と /lib/systemd/system の以下のファイルだと思う。

• corosync.service
• openvswitch-switch.service
• lvm2-cluster-activation.service
• lvm2-clvmd.service
• open-iscsi.service

この内、open-iscsi.service はアップデートの過程で元のファイルに戻っているので、バックアップファイルだけ削除すれば OK のはず。
他にも弄っているファイルがあるかもしれないので、各自対応しておこう。

っと、systemd を弄る前に、個別にクラスタを止めておいた方がいいな。

(aquarius) $ sudo pcs cluster stop aquarius
(aquarius) $ sudo systemctl stop corosync
(aquarius) $ sudo systemctl stop pacemaker
(aquarius) $ sudo systemctl stop pcsd
(aquarius) $ mkdir ~/systemd.unit
(aquarius) $ sudo mv /etc/systemd/system/corosync.service ~/systemd.unit/
(aquarius) $ sudo mv /etc/systemd/system/openvswitch-switch.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-cluster-activation.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-cluster-activation.service.orig /lib/systemd/system/lvm2-cluster-activation.service
(aquarius) $ sudo mv /lib/systemd/system/lvm2-clvmd.service ~/systemd.unit/
(aquarius) $ sudo mv /lib/systemd/system/lvm2-clvmd.service.orig /lib/systemd/system/lvm2-clvmd.service
(aquarius) $ sudo rm /lib/systemd/system/open-iscsi.service.orig

systemd の unit ファイルを再読込して、OS ごと再起動してみよう。

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl reboot

う～ん。やっぱり corosync.service の起動に失敗する。
OpenvSwitch より後に起動させる必要があるみたいだな。

(aquarius) $ sudo EDITOR=vi systemctl edit corosync.service

---空のエディタが起動するので、以下のように作成

[Unit]
After=openvswitch-nonetwork.service
[Service]
ExecStartPre=/bin/sleep 5

---
これでいいのかな？

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl reboot

どうやら上手くいったよう。
sagittarius にも同じ作業を適用しておこう。

ストレージプールのStart/Stopをリソース化

前回、gfs2マウントまでリソース化して、これで環境が整ったかと思ったんだけど、別の問題が発生した。
kvm/libvirt で default という名前がつけられたストレージプールが空っぽになってしまっている、という状態だ。
default というストレージプール、実際のパスは /var/lib/libvirt/images になっている。

そもそも、 /var/lib/libvirt 自体が外部ディスクで、今回の一連の作業でこの領域のマウント自体をクラスタ制御にした。

考えてみたら当たり前で、/var/lib/libvirt のマウントより先に、kvm/libvirt が起動する。kvm/libvirt では default ストレージプールは自動起動になっているため、/var/lib/libvirt がマウントされる前に default ストレージプールが起動してきて、中身が空っぽの /var/lib/libvirt/images を見て、空のストレージプールとして定義された、というわけだ。
(ウチの環境では、/var/lib/libvirt のマウント前に、/var/lib/libvirt/images というディレクトリが存在している。もし存在して無ければ、 default プールの自動起動に失敗し、default プールが停止していると思う。)

ストレージプールを start する作業を gfs2 ファイルシステムマウントの後に、stop する作業を gfs2 ファイルシステムマウントの前に実行する必要がある。

gfs2 マウントがクラスタリソースなので、ストレージプールの stop/start もクラスタリソースとして定義してしまうのがスマートだろう。

ということで、ストレージプールの start/stop をするリソースエージェントを探したのだが…見つからない。存在していないようだ。

ということは、リソースエージェントを自作する必要があるということだ。
面倒だが、この辺を参考に作っていくことにしよう。

まずは、リソースエージェントを配置するパス。
/usr/lib/ocf/resource.d/プロジェクト名/ に配置することになるらしい。他の環境と被って欲しくないので、プロジェクト名は kvmcluster にしよう。
$ sudo mkdir /usr/lib/ocf/resource.d/kvmcluster

そして、とりあえず以下のようにファイルを作成してみる。
$ sudo vi /usr/lib/ocf/resource.d/kvmcluster/virt-pool
-----ココから

#!/bin/bash
#
#   Resource Agent for libvirt storage pool resources.
#
#   License:      GNU General Public License (GPL)
#   Original
#
# Initialization:
: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/lib/heartbeat}
. ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs
virt_pool_meta_data() {
cat <<EOF
<?xml version="1.0"?>
<!DOCTYPE resource-agent SYSTEM "ra-api-1.dtd">
<resource-agent name="virt-pool">
  <version>0.1</version>
  <longdesc lang="en">
This is a resource agent to start / stop libvirt storage-pool.
  </longdesc>
  <shortdesc lang="en">start / stop storage-pool</shortdesc>
  <parameters>
    <parameter name="poolname" unique="0" required="1">
      <longdesc lang="en">
      Name of Storage pool
      </longdesc>
      <shortdesc lang="en">Pool Name</shortdesc>
      <content type="string"/>
    </parameter>
  </parameters>
  <actions>
    <action name="start"        timeout="20" />
    <action name="stop"         timeout="20" />
    <action name="monitor"      timeout="20"
                                interval="10" depth="0" />
    <action name="meta-data"    timeout="5" />
    <action name="validate-all"   timeout="20" />
  </actions>
</resource-agent>
EOF
}
virt_pool_usage() {
    return $OCF_SUCCESS
}
virt_pool_validate_all() {
    #check_binary virsh
    ocf_run -q virsh pool-info $OCF_RESKEY_poolname
    case "$?" in
        0)
            rc=$OCF_SUCCESS
            ocf_log debug "poolname is OK"
            ;;
        1)
            rc=$OCF_ERR_CONFIGURED
            ocf_log err "No pool"
            ;;
    esac
}
virt_pool_monitor() {
    local rc
    # 設定が不正な場合は即終了する
    virt_pool_validate_all || exit $?
    virsh pool-info $OCF_RESKEY_poolname | grep State: | grep running > /dev/null 2>&1
    # 0: pool-start済
    # 1: pool-stop済
    # それ以外: エラー
    case "$?" in
        0)
            rc=$OCF_SUCCESS
            ocf_log debug "Resource is running"
            ;;
        1)
            rc=$OCF_NOT_RUNNING
            ocf_log debug "Resource is not running"
            ;;
        *)
            ocf_log err "Resource has failed"
            exit $OCF_ERR_GENERIC
    esac
    return $rc
}
virt_pool_stop() {
    ocf_run -q virsh pool-destroy $OCF_RESKEY_poolname
    return $OCF_SUCCESS
}
virt_pool_start() {
    ocf_run -q virsh pool-start $OCF_RESKEY_poolname
    return $OCF_SUCCESS
}
case $__OCF_ACTION in
meta-data)      virt_pool_meta_data
                exit $OCF_SUCCESS
                ;;
usage|help)     virt_pool_usage
                exit $OCF_SUCCESS
                ;;
esac
virt_pool_validate_all || exit $?
case $__OCF_ACTION in
start)          virt_pool_start;;
stop)           virt_pool_stop;;
status|monitor) virt_pool_monitor;;
validate-all)   virt_pool_validate_all;;
*)              virt_pool_usage
                exit $OCF_ERR_UNIMPLEMENTED
                ;;
esac
rc=$?
ocf_log debug "${OCF_RESOURCE_INSTANCE} $__OCF_ACTION returned $rc"
exit $rc

-----ココまで
必要最小限の機能だけ盛り込んだ。
エラーハンドリング等、甘い部分もあるが、とりあえずの実装なので良しとする。
正規のリソースエージェントがリリースされたら、それに移行すればいい。

作成したらパーミッション変更。
$ sudo chmod 755 /usr/lib/ocf/resource.d/kvmcluster/virt-pool

テスターがあるので実行してみる。
テストの時、実際にプールのStart/Stopが行われるので、default プールは止めておく。
また、合わせて default プールの自動起動も止めておく。(sagittarius/aquarius 両方やっておくのを忘れないように)
$ virsh pool-destroy default
$ virsh pool-autostart default --disable
$ virsh pool-list --all

そしたらテスター実行
$ sudo ocf-tester -n ocf:kvmcluster:virt-pool -o poolname=default /usr/lib/ocf/resource.d/kvmcluster/virt-pool
最後に
/usr/lib/ocf/resource.d/kvmcluster/virt-pool passed all tests
と出てきたらなんとか成功だ。
もしダメだったら、詳細表示状態でテスターを実行してみよう。もしかしたら何が悪いか分かるかも。
$ sudo ocf-tester -v -n ocf:kvmcluster:virt-pool -o poolname=default /usr/lib/ocf/resource.d/kvmcluster/virt-pool

さて、このリソースエージェントを使って、defaultプールの start/stop を作るのだが…認識されているかな？
$ sudo pcs resource list
どうやら出てきたようだ。

詳細は？
$ sudo pcs resource describe ocf:kvmcluster:virt-pool
出た。

じゃぁコレを使ってリソースを作ってみよう。
$ sudo pcs resource create pool-default ocf:kvmcluster:virt-pool \
  poolname=default \
  --clone \
  --disabled

$ sudo pcs resource show
pool-default-clone が定義されたはずだ。
ただ、今はまだ disabled のはず。

$ sudo pcs resource show pool-default-clone
詳細も見える。

リソースの前後関係・起動ノード関係を設定しておく。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start shared-pool-clone then pool-default-clone
$ sudo pcs constraint colocation add pool-default-clone with shared-pool-clone
$ sudo pcs constraint show --full

設定できたらリソースを有効化してみよう。
$ virsh pool-list --all
$ sudo pcs status
$ sudo pcs resource enable pool-default
$ sudo pcs status
$ virsh pool-list --all
無事に defaultプール が起動してきたはず。
念のために中身も見てみよう。
$ virsh vol-list default
中身も見れる。

shared-pool-clone が落ちれば、pool-default-clone も落ちるはず。
$ sudo pcs status
$ sudo pcs resource disable shared-pool-clone
$ sudo pcs status
落ちた。
$ sudo pcs resource enable shared-pool-clone
$ sudo pcs status
上がった。

OS再起動等して、リソースが起動、プールが起動するところも確認しておこう。

問題が無ければ、このあたりで一度システムバックアップを取得しておこう。
1台ずつ、クラスタを停止してからバックアップを取るように。
$ sudo pcs cluster stop aquarius --force
$ sudo pcs status
(ここでaquariusをバックアップ)
$ sudo pcs cluster start aquarius
$ sudo pcs status
$ sudo pcs cluster stop sagittarius --force
$ sudo pcs status
(ここでsagittariusをバックアップ)
$ sudo pcs cluster start sagittarius
$ sudo pcs status

ふぅ。これでなんとかなったか？
あと少し、整理・調整したいので、もう少し続ける。

各種リソース作成

さて、いよいよ大詰めだ。

各種リソースの作成、リソースの制約の付与、そして動作確認だ。
今回必要なのは、

• dlm
• clvmd
• gfs2マウント

の3つのはず。
で、依存関係としては…
dlm起動→clvmd起動→gfs2マウント
となる様子。
＃あれ？ってことはgfs2を使用しないクラスターLVMでも、dlmは必要なのか？
＃nfsクラスター構築時に検証してみよう。

まずはdlmリソースの作成
$ sudo pcs resource show
(sagittarius) $ sudo pcs resource create dlm \
  ocf:pacemaker:controld \
  op monitor \
       interval=30s \
       on-fail=fence \
     clone \
     interleave=true \
     ordered=true
$ sudo pcs resource show
リソースが出来たし、いきなり起動した。
詳細確認
$ sudo pcs resource show dlm-clone

sagittarius/aquarius どちらも ps コマンドで確認したら、dlm プロセスが動き出しているはずだ。

続いて、clvmdリソースの作成。
(sagittarius) $ sudo pcs resource create clvmd ocf:heartbeat:clvm \
  op monitor interval=30s on-fail=fence \
  clone \
  interleave=true \
  ordered=true
$ sudo pcs status
数秒後、sagittarius/aquarius 両ノードで clvmd-clone リソースが起動してくるはずだ。
$ ps -ef | grep clvmd | grep -v grep
プロセスも起動してくる。

clvmd-clone リソースを停止すれば、clvmdプロセスも落ちるはず。
$ sudo pcs resource disable clvmd-clone
$ sudo pcs status
$ ps -ef | grep clvmd | grep -v grep
$ sudo pcs resource enable clvmd-clone
$ sudo pcs status
$ ps -ef | grep clvmd | grep -v grep

clvmd-clone リソースの追加ができたので、dlm リソースとの順序と起動ノードの設定。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start dlm-clone then clvmd-clone
$ sudo pcs constraint colocation add clvmd-clone with dlm-clone
$ sudo pcs constraint show --full

そういえば、clvmd リソースが起動したら、過去に作ってあった共有ボリューム(kvmcluster VG)もアクティベートされたぞ。

そしたら、ファイルシステムマウントのリソース作成。
(sagittarius) $ sudo pcs resource create shared-pool Filesystem \
    device="/dev/kvmcluster/var-lib-libvirt" \
    directory="/var/lib/libvirt" \
    fstype="gfs2" \
    op monitor interval=10s on-fail=fence clone interleave=true
$ sudo pcs status
動き出した！
$ sudo pcs resource show shared-pool
$ df /var/lib/libvirt
両ノードでちゃんとマウントされた！

clvmdの時と同じように、順序と起動ノードの設定をしておこう。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start clvmd-clone then shared-pool-clone
$ sudo pcs constraint colocation add shared-pool-clone with clvmd-clone
$ sudo pcs constraint show --full

できた！

しかし、別の問題が発生。

次回はその問題の確認と対策だ…。結構メンドウだよ…。

2019/06/20 追記
ファイルシステムマウントのリソース、クローンリソース化するのなら、force_clones というパラメータを yes に設定しておく必要があるようだ。
実際のところ、違いがわからなかったんだけど、マニュアル上はそう書いてあるよう。
というわけで、設定を変更しておく。

$ sudo pcs resource update shared-pool force_clones=yes
$ sudo pcs resource show shared-pool

設定が反映されていれば OK だ。

fence-agent のインストールと設定

dlm を使用するのなら、stonith/fence の設定が必須らしい。参ったな。
というわけで、インストールと設定を行おう。

$ sudo apt-get update
$ sudo apt-get install fence-agents

さて、フェンスデバイスだが…、今回使用している環境は、ベアメタル、所謂物理マシンだ。
しかも普通のPCで、IPMIは搭載していない。UPSに繋いでいるわけでもない。
使えそうなのは

• fence_mpath
• fence_sbd
• fence_scsi

あたりか…。ubuntu 1604 だと、fence_sbd は使えなかったような気がする…。

となると、fence_scsi か fence_mpath だけど、こちらはほぼ同じモノのようだ。
使うデバイスは、SCSI-3 PR(Persistend Reservation)に対応した共有ディスク。
iSCSI や FCデバイスだけど、家で FCデバイス なんて運用していない。
また、multipathd を動かしているので、fence_mpath を使うことになると思うのだが…。
fence_mpath は fence_scsi と違い、keyパラメータを指定する必要がある。
が…、「ノードごとに固有に設定」なのに、pcs stonith create で一発指定…。ノードごとにどうやって指定するのか分からない…。
デバイスは multipath にしておいて、stonith は fence_scsi でやってみるか。

しょうがないので、iSCSIストレージから、1GBの共有ディスクを追加する。混乱しないように「fence-device」とでも名付けておくか。

dmesg で確認すると sagittarius で /dev/sdk 、aquarius で /dev/sdi というデバイスで認識された。
(sagittarius) $ sudo multipath -a /dev/sdk
wwid が見える。(今回は 23166363164363639 だった)
(sagittarius) $ sudo vi /etc/multipath/bindings
-----
見つかったwwidを追加する。
fence-device 23166363164363639
-----
(sagittarius) $ sudo multipath -r /dev/sdk
これで、/dev/mapper/fence-device として認識されたはずだ。

aquarius でも同様に。
(aquarius) $ sudo multipath -a /dev/sdi
(aquarius) $ sudo vi /etc/multipath/bindings
-----
wwidの追加
fence-device 23166363164363639
-----
(aquarius) $ sudo multipath -r /dev/sdi

そうしたら、stonith/fence の設定だ。
fence_scsi は、デフォルトでは /var/run/cluster ディレクトリの下に情報を書き込む。
ところが、/var/run は tmpfs で、OS再起動のたびに中身が綺麗サッパリ消えてしまう。
そのため、/var/run/cluster というディレクトリそのものも消えてしまい、fence_scsi がファイルを作成するのに失敗してしまう。

/var/run 以下は tmpfiles という仕組みによって、OS起動時に作成してくれるのだが、そのための設定ファイルが漏れている。
もしかしたら、Ubuntu1604のバグで、Ubuntu1804なら解決しているのかもしれないが…。

というわけで、OS起動時に /var/run/cluster ディレクトリが作成されるように設定ファイルを作っておく。
細かいところや配置ディレクトリは個別に調べてもらうとして、sagittarius/aquarius で以下のように実行。
$ sudo vi /etc/tmpfiles.d/var-run.conf
-----中身は以下の1行
d /var/run/cluster - - - -
-----
これを作成したら、OS再起動して反映させよう。
$ sudo systemctl reboot
$ ls -ld /var/run/cluster
ディレクトリが作成されているはずだ。

やっと準備が出来た。stonith/fence の作成だ。
(sagittarius) $ sudo pcs stonith create scsi-fence fence_scsi \
  pcmk_host_list="sagittarius aquarius" \
  devices=/dev/mapper/fence-device \
  verbose \
  meta provides=unfencing

$ sudo pcs status
いきなり scsi-fence が動き出したと思う。
＃動いていなければ、sudo pcs resource cleanup scsi-fence 等でクリーンアップしよう。

scsi-fence は、稼働しているノードがダウンしたら、もう片方のノードで動き出すはずだ。
sagittarius/aquarius を交互にリブートしてみて、sudo pcs status で確認してみよう。
問題なく動いていたら、stonith/fence の完成だ。

これでようやくリソースの作成に入れるかな？

クラスタパラメータ設定

ここまで設定できれば、ブラウザからもアクセス出来ると思う。
ブラウザを起動して、https://(sagittariusかaquariusのIP):2224/ にアクセスすれば、ブラウザから設定確認や設定変更が出来るんじゃないか？
と思ったけど、pcsd(ブラウザでアクセスする先のサービス)に、今回のクラスタを組み込ませていなかった。
ブラウザでアクセスし、Add Existing から組み込んでおこう。設定をブラウザから確認できるのはなんだかんだ便利だ。

クラスタの基本パラメータを設定しておこう。
今作っているクラスタは2Nodeで、既にcorosync.confには2Nodeパラメータは設定されている。
設定しておきたいのは

• 片方落ちていて、片方しか動かせない時の起動時状態
• スプリットブレイン時に働くstonithをどうするか？
• スプリットブレインが発生した時の各ノードグループの動作

の3点。
今回の構成的には、
ハートビート/Stonith用のLANは存在しない。(サービスLANと共有)
ストレージはiSCSIで、専用LANは無い。(サービスLANと共有)
だ。
そもそもスプリットブレインが発生するシチュエーションはほとんど無い。
そのため、後者2点はほとんど考えなくて良いのだが、一応設定しておく。

まずは1点目。
ただ、これを実行すると、作ったクラスタが破壊されて再構築される。今はまだ何も設定していないから大丈夫なはずだ。
(sagittarius) $ sudo pcs cluster setup --name kvmcluster sagittarius aquarius --wait_for_all=0 --force
(sagittarius) $ sudo pcs cluster start --all
(sagittarius) $ sudo pcs cluster enable
せっかく作ったクラスタが破壊されて作り直されるのが嫌なら、以下の手順だ。
(sagittarius) $ sudo pcs cluster stop --all
(sagittarius) $ sudo vi /etc/corosync/corosync.conf
-----
two_node: 1 の上に、以下の行を追加する。
wait_for_all: 0
-----
(sagittarius) $ sudo pcs cluster sync
(aquarius) $ sudo cat /etc/corosync/corosync.conf
wait_for_all:0 が反映されているのを確認する。

wait_for_all の設定が出来たら、反映を確認しておこう。
$ sudo corosync-quorumtool -s
Flags に有ったはずの WaitForAll が無くなったはずだ。

これで、片方故障していても、起動停止出来るはずだ。
試してみよう。
(sagittarius) $ sudo pcs cluster stop aquarius --force
(sagittarius) $ sudo pcs status
aquariusが切り離されたはず。
(sagittarius) $ sudo pcs cluster stop sagittarius --force
(sagittarius) $ sudo pcs status
クラスタダウンしている。
(sagittarius) $ sudo pcs cluster start sagittarius
(sagittarius) $ sudo pcs cluster enable sagittarius
(sagittarius) $ sudo pcs status
1ノード(sagittarius)のみでも、partition with quorum になったはずだ。
(sagittarius) $ sudo corosync-quorumtool -s
Quorate が Yes のはず。
これで「片方落ちていて、片方しか動かせない時の起動状態」の設定が完了。

次は stonith だ。過去には色々検証したが、今の構成だと stonith はあまり意味が無いと思われるので、無効化してしまう。
$ sudo pcs property show --all
stonith-enabled: が true になっているはずだ。
これを無効化してしまおう。
$ sudo pcs property set stonith-enabled=false
$ sudo pcs property show --all
stonith-enabled: が false に変わったのが確認できるはずだ。

と思ったのだが、stonith-enabled が falseの場合、dlm や dlmに依存するリソース(clvmやgfs2)が起動できなくなるようだ。
ということで、デフォルトに戻しておこう。
$ sudo pcs property set stonith-enabled=
$ sudo pcs property show --all
これでデフォルト(true)に戻った。

ってことは、fence-device も定義しないとアカンのかなー。

最後に、スプリットブレイン(というか、2ノードなのでクォーラムロストか)が発生した時の挙動だ。
$ sudo pcs property show --all
no-quorum-policy: が stop に設定されている。これを freeze に設定し直す。
$ sudo pcs property set no-quorum-policy=freeze
$ sudo pcs property show --all
設定が変わったのが確認できる。
ちなみに、no-quorum-policyは、stop/freeze/ignore/suicide の4つが指定出来るようだ。

これで、基本的な初期パラメータ設定はおしまいかな。

クラスタ作成

さて、ココからクラスタを構築していく。

ノード間のhaclusterの結びつけ。
これは確か、片方のノードから実施すればOKだったはずだ。
(sagittarius) $ sudo pcs cluster auth sagittarius aquarius -u hacluster
sagittarius/aquairsuの両方ともAuthorizedになればOK。

続いてクラスタ構築。
こちらも片方から実施すればOK。
クラスタ名は、既に gfs2 で使っている kvmcluster にしないと、ファイルシステムマウントでコケるはずなので、間違えないように。
(sagittarius) $ sudo pcs cluster setup --name kvmcluster sagittarius aquarius
Success になっていればOK

ちょっと見てみよう。
$ sudo pcs status
おっと、まだクラスタ起動していないか。

クラスタを起動させる。
(sagittarius) $ sudo pcs cluster start --all

もう一度確認。
$ sudo pcs status

おや、corosyncとpacemakerが自動起動になっていないっぽいぞ？
確認してみる。
$ sudo systemctl status corosync
$ sudo systemctl status pacemaker

自動起動にしておくか。
ここでpacemakerを自動起動にするかどうかは、クラスタの運用ポリシーによる。
自動起動になっている場合、サーバ障害が発生し、片肺運転になった後、サーバ復旧すると、自動的にクラスタに組み込まれてしまう。
OSの稼働を確認し、問題ないと判断できてからクラスタに組み込むような信頼性を求める場合は、自動起動はOffにしておいた方がいいかもしれない。
$ sudo systemctl is-enabled corosync
$ sudo systemctl enable corosync
$ sudo systemctl is-enabled corosync
$ sudo systemctl is-enabled pacemaker
$ sudo systemctl enable pacemaker
$ sudo systemctl is-enabled pacemaker

$ sudo pcs status

OS再起動して確認しておこう。
$ sudo systemctl reboot
$ sudo pcs status

作成されている corosync.conf も確認しておこう。
$ cat /etc/corosync/corosync.conf
sagittarius と aquarius が nodelist に入っていて、two_node フラグが付与されているのが確認できるはずだ。
$ sudo corosync-quorumtool -s
Expected votes が 2、Quorum が 1、Flags に 2Node Quorate WaitForAll がついているのが確認できる。

ココまで確認できたら、クラスタの初期構築は完了だ。
次はクラスタの基本パラメータの設定を行う。

おっと忘れてた。Ubuntu1604のpacemakerは、インストーラのバグなのか、/etc/corosync/uidgid.d というディレクトリが作られない。
無くても稼働に問題はないが、一応作っておこう。
$ sudo mkdir /etc/corosync/uidgid.d
$ sudo chmod 755 /etc/corosync/uidgid.d
$ sudo chown root:root /etc/corosync/uidgid.d

クラスタ定義の削除

次はクラスタ定義の削除だ。

これまで、手作業でcorosync等の設定を実施していたが、これらのファイルが存在する状態でpacemakerでクラスタを組もうとすると、「このノードは既に他のクラスタに組み込まれているで」とエラーになってしまう。

というか、corosync.conf が残っているので、中途半端にクラスタが組まれている状態になっている。
$ sudo pcs status

そのため、クラスタ定義(corosync.conf)を削除する。
コマンド一発で実施できるので、それで構わない。
$ ls -l /etc/corosync
$ sudo pcs cluster destroy
$ sudo pcs status
$ ls -l /etc/corosync
他にも、/etc/corosync に過去のゴミが残っていたら削除しておこう。

これでキレイになったので、次回からクラスタの構築だ。

hacluster アカウントにパスワードを付与

pacemakerのインストールが終わったら、haclusterというアカウントが出来ているはずだ。
こちら、pcsd同士の通信に使うものなので、クラスタを構成するサーバ(sagittarius/aquairus)全体で統一のパスワードを設定しておく。
$ sudo passwd hacluster
それだけ。

pcs のインストール

続いて、pcsのインストールだ。
コレをインストールすれば、pacemaker諸々インストールされるので、まとめてインストールしておく。
$ sudo apt-get update
パッケージ追加インストールの前に、最新のパッチは適用しておこう。
$ LANG=C sudo apt-get dist-upgrade
$ sudo apt autoremove
$ sudo systemctl reboot

リブートが終わったらパッケージインストール。
$ sudo apt-get update
$ sudo apt-get --simulate install pcs
$ sudo apt-get install pcs

インストール終わったら、念の為OS再起動しておこう。
$ sudo systemctl reboot

最後に、systemdのサービス状態をチェック。failedが無ければ一旦終了。
$ systemctl status

dlm.conf の削除

dlm.conf はデフォルトのままで良いことが分かったので、このタイミングで消しておく。
$ ls -l /etc/dlm
$ sudo rm /etc/dlm/dlm.conf
$ ls -l /etc/dlm
他にもゴミが残っていたら削除しておこう。

dlm.service の停止と自動起動解除

dlm.service も同様に実施する。

同じく、両方のサーバで実施だ。
$ systemctl status dlm.service
$ sudo systemctl stop dlm.service
$ systemctl status dlm.service
$ systemctl is-enabled dlm.service
$ sudo systemctl disable dlm.service
$ systemctl is-enabled dlm.service

こちらも念の為、再起動しておこう。
$ sudo systemctl reboot
$ systemctl status dlm.service

おしまい。

clvmdの停止と自動起動解除

さて、clvmdの停止と自動起動解除だ。
clvmd自体、クラスタリソースにする予定なので、このタイミングで解除しておく。
が、clvmd自体は他のサービスに紐付けられて起動している。
lvm2-cluster-activation.service のようだ。

やっぱり、sagittairus/aquarius 両方の作業だ。
$ systemctl status lvm2-clvmd.service
$ systemctl status lvm2-cluster-activation.service
$ sudo systemctl stop lvm2-cluster-activation.service
$ systemctl status lvm2-cluster-activation.service
$ systemctl status lvm2-clvmd.service
$ sudo systemctl is-enabled lvm2-cluster-activation.service
$ sudo systemctl disable lvm2-cluster-activation.service
$ sudo systemctl is-enabled lvm2-cluster-activation.service

一度再起動して確認しておこう。
$ sudo systemctl reboot
$ systemctl status lvm2-cluster-activation.service
$ systemctl status lvm2-clvmd.service
両方止まっていたら完了だ。