2019年7月21日日曜日

リソースが起動しない

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

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

2019年7月10日水曜日

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 を導入しないと駄目なので要注意。

2019年7月7日日曜日

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 にバージョンアップしていくことにする。

2019年7月1日月曜日

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にバージョンアップしてから再確認しよう。
それまでは、上に記載した暫定対処で回避することにする。

2019年6月24日月曜日

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

謎な挙動が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 の設定を入れていた。
ちゃんと設定項目の意味を理解してれば、こんなに悩まなかったのに…。

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

2019年6月23日日曜日

仮想マシンのクラスタリソース化その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点だ。
ちょっと調べたがまだ解決していない。
解決できるか分からないが、次回からちょっと調査をする。

2019年6月17日月曜日

仮想マシンのクラスタリソース化その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

2019年6月16日日曜日

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 にも同じ作業を適用しておこう。

2019年6月14日金曜日

ストレージプールの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

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

2019年6月11日火曜日

各種リソース作成

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

各種リソースの作成、リソースの制約の付与、そして動作確認だ。
今回必要なのは、
  • 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 の完成だ。

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

2019年6月9日日曜日

クラスタパラメータ設定

ここまで設定できれば、ブラウザからもアクセス出来ると思う。
ブラウザを起動して、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つが指定出来るようだ。

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

2019年6月8日土曜日

クラスタ作成

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

ノード間の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
両方止まっていたら完了だ。

/var/lib/libvirt の自動マウント解除

仮想マシンの停止が終わったら、/var/lib/libvirt をアンマウント、自動マウントの解除をする。
クラスタ化する上で、各種サービスの停止などもあるので、アンマウントしないと作業が続行できない。
ちなみに、初期には /etc/libvirt、/var/lib/libvirt、/var/log/libvirt を共有ボリュームとして定義していたが、結局 /var/lib/libvirt 以外は共有化させる意味が無かったので、解除している。

作業は sagittarius/aquarius 両方で実施すること。
$ grep /var/lib/libvirt /etc/mtab
$ sudo systemctl stop /var/lib/libvirt
$ systemctl status /var/lib/libvirt
$ grep /var/lib/libvirt /etc/mtab

アンマウントしたら、自動マウントを解除する。
$ grep /var/lib/libvirt /etc/fstab
$ sudo vi /etc/fstab
-----
/var/lib/libvirt をマウントしている行をコメント化する
-----
$ sudo systemctl daemon-reload
$ systemctl status /var/lib/libvirt
定義が消えていたらOKだ。

どうやら、過去の作業で内蔵ディスクの方の /var/lib/libvirt を空にしていなかったらしい。
ま、いいか。

仮想マシンの全停止

続いて、仮想マシンを全停止させる。
理由は簡単で、これからsagittarius/aquariusをpacemakerクラスタ化させる上で、クラスタリソースにする予定の/var/lib/libvirtをアンマウントしないといけないからだ。
OSの再起動も発生するかもしれないしね。

というわけで、稼働している仮想マシンは全停止させておこう。

2019年6月7日金曜日

/etc/hostsにエントリ追加

さて、最初はsagittarius/aquariusで相互に名前解決できるように、/etc/hostsにエントリ追加だ。
どちらのホストも、デフォルトで127.0.1.1が自分のホスト名を指すようになっていると思う。
それをコメントにして、自身のIPと自身のホスト名、相手のIPと相手のホスト名を記載しよう。
(sagittarius) $ sudo vi /etc/hosts
-----
以下の行はコメント化
127.0.1.1       sagittarius
以下の2行を追記
192.168.55.130  sagittarius
192.168.55.131  aquarius
-----
名前解決できているか確認。
(sagittarius) $ ping -c 4 sagittarius
(sagittarius) $ ping -c 4 aquarius
どちらも、192.168.55.*のアドレスにping打てていればOKだ。

続いてaquarius
(aquairus) $ sudo vi /etc/hosts
-----
以下の行はコメント化
127.0.1.1       aquairus
以下の2行を追記
192.168.55.130  sagittarius
192.168.55.131  aquarius
-----
(aquarius) $ ping -c 4 sagittarius
(aquarius) $ ping -c 4 aquarius
アドレスに間違いがなければOK。

簡単だけどココまで。

2019年6月6日木曜日

ホストのpacemaker化作業リスト

さて…ホスト側である sagittarius/aquarius は、/var/lib/libvirt も共有化している。
これ、本当に共有していいのだろうか…?

それはとりあえず置いておいて、sagittarius/aquarius を pacemaker化するための作業リストを作っておこう。
抜け漏れはあると思うので、都度追記していく。
  1. /etc/hosts に相互に名前解決できるようにエントリ追加
  2. 仮想マシンの全停止
  3. /var/lib/libvirt の自動マウント解除
  4. clvmdの停止と自動起動解除
  5. dlm.service の停止と自動起動解除
  6. dlm.conf の削除
  7. pcs のインストール
  8. hacluster アカウントにパスワードを付与
  9. クラスタ定義の削除
  10. クラスタ作成
  11. クラスタパラメータ設定
  12. fence-agent のインストールと設定
  13. dlmリソース、clvmdリソース、gfs2リソース作成
  14. ストレージプールのStart/Stopをリソース化
  15. systemd設定見直し
  16. 仮想マシンのクラスタリソース化その1
  17. 仮想マシンのクラスタリソース化その2
  18. リソースが勝手に再起動する
  19. fence_scsi がコケる
  20. ノード再起動で dlm がハング(他にも問題発生、一旦停止)
といった感じだろうか…。
次回からこれに合わせて設定していこう。

一旦20項目書いたが、色々問題が出てきたのでここで切る。
18.04 にバージョンアップ後、別途書こうと思う。

2019年6月5日水曜日

ホスト側のpacemaker化の前に

pacemakerでgfs2を運用する方法がある程度見えてきたので、メインマシンのホスト(sagittarius/aquarius)のpacemaker化を進めたい。
が、その前にやっておかなきゃいけないことがある。

今、KVMホストであるsagittarius/aquariusの2台は、/etc/libvirtと/var/lib/libvirtの2箇所をgfs2で共有している。
が、調べてみたら/etc/libvirtはやはり、共有化してはいけないことが分かった。

というわけで、両サーバとも/etc/libvirtをローカル化(内蔵ディスク化)することにする。
サイズは1GBもあれば十分。
空き領域を確認する。
$ sudo vgdisplay vg-root
Free PE / Size が数十GB空いていればOKだ。(システムバックアップ取得のために、スナップショット領域を必要とするので、1GBきっちりしか空いてなかったらダメだぞ)

$ sudo lvcreate -L 1G -n lv-etc-libvirt vg-root
$ sudo mkfs.ext4 /dev/vg-root/lv-etc-libvirt
暫定のマウントポイントを作成する。
$ sudo mkdir /mnt/libvirt
マウント
$ sudo mount /dev/vg-root/lv-etc-libvirt /mnt/libvirt

そしたら、ファイルをコピーする。
$ cd /etc
$ sudo tar cSf - libvirt | (cd /mnt ; sudo tar xSf -)
$ sudo ls -alR /etc/libvirt > /tmp/etc-libvirt-gfs2.list
$ sudo ls -alR /mnt/libvirt > /tmp/etc-libvirt-ext4.list
$ diff -w /tmp/etc-libvirt-gfs2.list /tmp/etc-libvirt-ext4.list
ディレクトリのサイズ差が若干あるのは、gfs2とext4のファイルシステムの違いによるものだ。lost+foundの有無も同様。

ファイルコピーが終わったら、一時マウントを解除し、暫定マウントポイントを削除する。
$ sudo umount /mnt/libvirt
$ sudo rmdir /mnt/libvirt

続いて、既存の/etc/libvirtをアンマウントし、/etc/fstabを書き換え、新しい/etc/libvirtをマウントする。
$ sudo systemctl stop /etc/libvirt
$ sudo vi /etc/fstab
-----
/etc/libvirtのマウント行をコメント化し、以下の行を追加する。
/dev/mapper/vg--root-lv--etc--libvirt /etc/libvirt ext4 defaults 0 2
-----

マウントする
$ sudo systemctl daemon-reload
$ sudo systemctl start /etc/libvirt
$ df /etc/libvirt
$ grep /etc/libvirt /etc/mtab
新しいファイルシステムの方(vg-rootの方)がマウントされていたら、念の為libvirt-binをリロードする。
$ sudo systemctl reload libvirt-bin
$ virsh list --all

システムバックアップの対象ボリュームが増えたので、定義ファイルを追加しておく。
$ sudo -i
# cd ~/backup/etc/fsconfig
# vi 0030_lv-etc-libvirt
-----
#
# USELVM:
# Area to be backed up or LVM region, simple partition of the flag.
# Specify a Yes in the case of LVM of LVOL area.
#
USELVM=Yes

#
# VOLNAME:
# You want to specify the volume device name of the target volume.
# For simple partition, sda1 and sda2 like.
# You can easily find LVM of LVOL area, specify the LVOL name (lvol1, etc.).
#
VOLNAME=lv-etc-libvirt

#
# MOUNTPOINT:
# Specify the mount point of the target area.
#
MOUNTPOINT=/etc/libvirt

#
# SNAPSIZE:
# If the area of interest was the LVM region, we want to create
# a LVM Snapshot.
# It will specify the capacity of the Snapshot area.
# ex.
#   SNAPSIZE=32M
#   SNAPSIZE=320M
# If you specify a larger size than the capacity of the backup target,
# it will be the same capacity as the size of the backup target.
#
SNAPSIZE=32M
-----

定義ファイルが作成できたら、バックアップを取っておこう。
# cd ~/backup/bin
# ./0000_backup
# exit

sagittarius/aquariusの両方で実施すること。
kvmclusterの方のetc-libvirt(旧/etc/libvirt)は念のために暫く残しておこう。

この後は、sagittarius/aquairusにpacemakerを導入し、gfs2をpacemakerで運用するための設定だ。
そして、1804へのアップグレードも控えている。
うまく進むといいけどな。

2019年6月4日火曜日

あれ?libvirt-binとか、pacemakerのリソースにしないとアカン?

gfs2をpacemakerで使用するための前提を色々調査していたけど…。

gfs2を複数ノードで使用するためには、clvmdとdlmが必要。
gfs2はKVMの仮想ディスク領域で使用。
ということは、KVMの構成要素であるlibvirt-binとかもpacemakerのクラスタリソースに入れて、gfs2より後に起動しないとアカンのかな?

いや、でも仮想マシンが起動していない限り、特に仮想ディスク領域を使用している様子は無いな…。

pacemakerのリソースには入れずに実行してみて、ダメだったらリソースに入れるか。

というわけで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をメンテナンスしよう。
バックアップ取るのを忘れないようにしないとね。

2019年6月3日月曜日

2ノード構成でのdlm.confやらcorosync.confやら

や~っと分かった!
2ノードクラスタが全然期待通りに動かなかったんだけど、どうやらこれで決定稿だ。
長かった…。

2ノードで組む場合は、corosync.conf は
  • auto_tie_breaker: 0 (もしくは未設定)
  • last_man_standing: 0 (もしくは未設定)
  • two_node: 1
にする必要があった。
auto_tie_breaker や last_man_standing をごにょごにょと 1 に設定したりしたもんだから、two_node が働いていなかったようだ。
で、dlm.conf は特にいじる必要なく、デフォルトのままで良かったようだ。

corosync.conf の wait_for_all は、2ノードの場合は自動で 1 に設定され、2ノードともpacemakerが起動しないと、サービス(リソース)は自動起動しない。
手作業でブロック解除すれば、片ノードだけでも起動する。
wait_for_all を 0 に設定すれば、片ノードだけでもリソースは起動する。
この辺は、クラスタに対してどこまで信頼性・可用性を求めるかによって変わってくるので、好きなように設定を。

あと、サービスは、pacemaker/corosync/pcsd の3つはOS起動時に自動起動(systemd管理下)にして、dlm/clvmd は pacemaker のリソースにする必要があるようだ。

これを元に、もう一度 gemini/cancer を見直そう…。

2019年6月2日日曜日

gemini停止時とcancer停止時の違い

おかしい…。
gemini/cancerのクラスタ構成で、cancerを停止させても、geminiから見ると with quorum (クォーラムを失っていない)状態なのに、geminiを停止させると WITHOUT quorum (クォーラムを失った)状態になる。
これが原因で、gemini停止→cancer停止を行おうとすると、cancerが無事に停止しない。
corosyncの設定もdlmの設定も、クラスタのプロパティも同じなのに、この違い。
なんだこりゃ…。


2019年5月11日土曜日

2ノード構成で両ノードでサービス稼働なのでstonithを捨てる

今回のgemini/cancerの構成は、2ノードで両方でgfs2をマウントする、という構成。
なので、そもそもstonithを稼働させる必要は無いのでは?
ということを調べてみたら、stonith自体を無効化させることが出来ることが分かった。

stonithが有効だと、stonithで定義したfence-deviceが有効にならないと、リソースが起動しない。
無理やり、シングルノードでfence-deviceを有効にする必要も無いので、無効にしてしまう。
無効の仕方は以下の通り。
クラスタのプロパティ確認。
sudo pcs property show --all
そもそも、--allをつけないと全パラメータが確認できないなんて…。
stonith-enabledがtrueになっていると思う。
ちなみに、最初にクラスタを作った時に指定したno-quorum-policyもfreezeに設定されているのが分かる。

stonithを無効化する。
sudo pcs property set stonith-enabled=false
確認。
sudo pcs property show --all

これでクラスタの状態を見てみると…fence-deviceは動いているな…。
クラスタを再起動させてみよう。
sudo pcs cluster stop --all
sudo pcs cluster start --all

あれ?今度は dlm が起動しなくなった…。これは一体…???

う~ん。dlmを動かすためには、stonithの設定は必須みたいだ…。
元に戻そう。
sudo pcs property set stonith-enabled=true
sudo pcs cluster stop --all
sudo pcs cluster start --all

dlmリソースのパラメータに「allow_stonith_disabled」というのがあった。
これをtrueに設定してみたが…、やっぱりダメっぽいな。

う~ん…。dlmの制御がネックだなぁ…。
問題になっているのは、dlm不意にが対向ノードと通信できなくなった時、dlmがダウンしてしまうってことなんだよなぁ。
これを解決できれば、全て通ると思うんだけど…。

2019年5月5日日曜日

あかん。まだや。

https://uramocha02.blogspot.com/2019/05/2.html
ココで、片方のノードがダウンした時の、もう片方のノードの運用について記載したけど、まだ問題があった。

上記は、片方のノードを正常停止(systemctl poweroff)してから、もう片方のノードを運用する、というスタンスで書いていた。
ところが、正常停止ではなく異常終了(電源停止などによるクラッシュ)の時は、生き残っている方のノードもマトモに稼働しない、ということが判明。
この時、生き残っている方のクラスタリソース、dlmが落ちるという事象が発生している。
これ、dlmのパラメータ(/etc/dlm/dlm.conf)を適切に設定すれば良いんだと思っていたんだが、どうも良くワカラン。そもそも、dlmに関するドキュメント類が薄すぎるんだよなー。

もっと調べないとアカンかなぁ。まぁdlmは、GFS2等の共有ファイルシステムを使っている時にのみ利用するデーモンだから、情報量少ないのはしょうがないか…。

イマイチ本運用まで到達出来ないなぁ。

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に戻す必要があるので、固定する機能は多分無いだろう。

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

2019年5月4日土曜日

まずはpcsdの導入と初期セットアップ(18.04)

というわけで、18.04の構成(pisces/aries)を使って、NFSクラスタを構築する。

最初はpcsdの導入だ。
sudo apt-get update
sudo apt-get dist-upgrade
(必要に応じて再起動)
sudo apt-get install pcs
合わせて、pacemakerもインストールされる。

pcsdは自動起動にセットされた。

16.04の時と同様、haclusterアカウントが出来ているはずなので、パスワードを設定しておく。
sudo passwd hacluster

ついで、pisces/ariesと管理ノードのleoに、pisces/ariesのホスト名とIPアドレスを/etc/hostsに記載しておく。

sudo vi /etc/hosts
(127.0.1.1に自身のホスト名が定義されていると思うので、それは外しておくこと)
相互にpingを打って、名前解決出来ていることを確認しておこう。

gemini/cancerの時は、ブラウザからクラスタを組んだが、今回はコマンドで組んでみることにする。
sudo pcs cluster auth pisces aries -u hacluster
sudo pcs cluster setup --name nfs-cluster pisces aries --force
sudo pcs status
sudo pcs cluster start pisces aries
sudo pcs status

これでクラスタの構成は出来たが、corosync.serviceとpacemaker.serviceが自動起動になっていない。(pcs cluster setup に --start --enable のオプションを付与しておけば、自動起動に設定されると思うが、今回は敢えて設定しなかった。)
両方共自動起動にしておく。(pisces / ariesの両方で実施しておくこと)
sudo systemctl enable corosync.service
sudo systemctl enable pacemaker.service

これで、OS再起動させても自動的にクラスタが構成されるはずだ。
試しておくこと。

2019年5月2日木曜日

16.04でのgfs2のpacemaker化(一部諦め)

あーでもないこーでもない、と色々検証していった結果、Ubuntu16.04でgfs2をpacemaker管理下に置くのは、いくつか問題があって厳しいことが分かった。

今現在分かっているのは、
  • 2ノードで稼働
  • 片方のノードが死亡
  • 生きている方のノードをメンテナンスのために再起動
という3つの条件が重なった時に、クラスタが上がってこない(厳密には、clvmdリソースが上がってこない)ということ。

クラスタ製品の仕様として、「クラスタを構成するノード数のうち、過半数のノードが起動しない限り、クラスタは稼働させない(3ノードの場合は2台以上、4ノード・5ノードの場合は3台以上)」というのがある。
これはクラスタとしては当然の仕様だ。

2ノードの場合、この条件を満たすためには、2台が正常稼働する必要がある。
クラスタを組んでいるのに、1台も障害を受け付けない、というのはクラスタとしては片手落ちだ。

そこで、クラスタ製品は幾つかの対策を施している。
2ノードのみ特定の設定をし、片方がダウンしてもサービスを継続させる、という仕組みもその一つ。今回使用しているpacemakerの場合、corosync.confに記載する「two_node」というパラメータが該当する。
確かにこのパラメータを1に設定しておけば、片方のノードがダウンしてもサービスは継続実行可能だ。
ただし、これはクラスタ稼働中の話だ。
片系ダウンしている時に、生きている方のノードを再起動させた場合、「クラスタ稼働中」ではなく「クラスタを起動させる時」に該当する。
この時、もう片方のノード(死んでいる方のノード)がクラスタに参加するのを待ってしまうため、いつまで経ってもクラスタが上がってこない。

pcsコマンドにある cluster quorum unblock というのが「ノード数が過半数に達しなくても、サービスを稼働させる」というコマンドのようなのだが、16.04で試してみても期待した動きにならない。

他のクラスタ製品では、「quorum disk」という設定を施すことで、上記の状態を回避することが可能になっている。これは、2ノードの片系ダウンだけでなく、4ノードなどの「偶数台クラスタ」による「スプリットブレイン」にも対応している。
quorum diskは、クラスタを構成しているすべてのノードに接続している共有ディスクで、ほんの僅かなサイズ(数百MB程度?)のディスクであればいい。

偶数クラスタがちょうど半分に分離してしまった場合(ちょうど半数のノードから応答が無かった場合)、予め定義していたquorum diskにロックを仕掛け、ロックを取得することが出来たノード、及びそのノードと通信可能な方のノードの組でクラスタサービスを継続し、ロックを取得できずに切り離されてしまった組はクラスタから離れる、という仕様だ。
これによって、スプリットブレインに対応している。
ちょうど、quorum diskをロックすることによって、ノード数(投票数)が一つ増えたイメージになる。

pacemaker にも同様の仕組みがあると思っていたのだが、なかなかその情報が見つけられず、スプリットブレイン対策がイマイチ分からなかった、というのが先日までの状態。

で、もう一度調査したところ、RHEL6.xまでは、そのものズバリのquorum diskという設定があったようだ。
ところが、RHEL7.xになって、quorum diskが無くなり、quorum deviceという仕組みに置き換わっていた。

Ubuntu16.04のpacemakerで同様の仕組みを探してみたが、corosyncのバージョン違いからか、quorum diskもquorum deviceも設定が無い。
Ubuntu18.04の方を見てみたら、quorum deviceという設定はあるようだ。

この時点で、quorum diskを使用したスプリットブレイン対策は施せないことが分かったのだが、quorum deviceの方を調べてみたら、クラスタ構成ノードとは別に、サーバが1環境必要であることが分かった。
2ノードクラスタを組むのに、3台必要、ということだ。

ちなみに、quorum deviceというのは、スプリットブレインが発生した時に、どちらの組でサービスを継続させるかを決定する、調停役として存在させるみたいだ。
HPE社のクラスタソフトであるServiceGuard for Linuxでは、確か「quorum server」と呼ばれるものに相当するようだ。

とまぁ色々書いてきたが、今のホストOS(sagittarius/aquarius)の2台では、16.04のpacemakerどころか、18.04のpacemakerでも不都合が起きる。
とりあえず、動かすことはできるので、2台のいずれかが故障しないことを祈るか、もう1台手配して、quorum deviceとしてセットアップするか…。

gfs2を使用するためのクラスタだけでなく、nfsサーバもクラスタ化することを考えているので、現状ではかなり厳しい状態なのが判明。果たしてどうするか?

18.04でquorum diskが使えるといいんだが…。

とりあえず今後は、16.04でのgfs2クラスタは一旦放置し、18.04のnfsクラスタの方を少し調査してみることにする。

2019年4月29日月曜日

シングルノード状態でのgfs2

いろいろ試しているうちに、いくつかまだ設定がおかしいと思われるところが見つかった。
致命的なのは、
  • 片方のノード(例えばcancer)が障害で起動できない
  • 生き残っている方のノード(この場合gemini)を再起動させると、clvmリソースが正常に立ち上がって来ない→gfs2が利用できない
という状態だ。
しかも、この状態だとgeminiが再起動できない。(停止処理でハングしてしまう)

調べていったら、起動後にdlmは起動するが、clvmdがうまく起動できていないのだが、clvmdがdlmと通信を行い、dlmがエラーを返すことで、clvmdが起動に失敗する、という流れのよう。
dlmがシングルノードで稼働している(相方が死んでいるので、シングルで稼働させても問題はない)という状態をうまく認識できていないのが問題のよう。

やっぱりdlmがネックになるなー。

2019年4月13日土曜日

Windowsのnetkvm.sys

ちょっと検証から離れて…。
KVM環境の上には、Linux以外にもWindowsを動かしている。
特に、以前から使っていたWindows7をKVMに移行し、それをメインのWindows環境として使っていた。(移行は、Windows7が持つシステムバックアップを使用した。)
KVM環境に移行してからのWindows7、実は頻繁にクラッシュしてた。クラッシュも、頻繁に発生するかと思ったらしばらく発生しなかったりで、原因が全然つかめなかった。
物理環境から、仮想環境へ移行したことが原因だと思っていたんだが…。

で、先日このWindows7をWindows10にアップグレードしたが、Windows10にしてからはもっとクラッシュ頻度が高まり、ほとんど使い物にならない状態だった。

が、Windows10になってから、クラッシュ時に表示される画面で、netkvm.sysというのが原因だということが分かった。
これは、Virtio NIC用のドライバだ。
調べてみると、このnetkvm.sys、非常に不安定らしい。いや、パラメータチューニングを適切に施せば、安定稼働するのかもしれないが…。

ただ、パラメータチューニングも時間がかかるし、チューニング中にもクラッシュしかねない。
なので、Virtio NICはやめて、rtl8139の完全仮想化デバイスに変えた。
変えてから数日しか経ってないが、非常に安定している。速度は出ないかもしれないが、こちらの方が快適だ。
とりあえず、netkvm.sysが安定するまでは、rtl8139を使用することにする。

2019年3月21日木曜日

corosync.confの追記

構成見直しの前に、/etc/corosync/corosync.confに2行ほど追加した。

追加したのは、quorumセクション。
追加前には provider: corosync_votequorum というエントリだけが存在していると思う。
そこに、
wait_for_all: 0
auto_tie_breaker: 1
の2行を追加した。

ホントは two_node: 1 というエントリも追加したいんだが、ノードを切り離して1ノード状態にすると、two_node: 1 というエントリも消えてしまう。
イマイチ良くわからない。

いずれにせよ、上で追加した2行は障害発生時の処理に関わるので、追加しておく。

クラスタ用LVMとファイルシステム作成(gfs2用)

フェンシングが全然わからず、すげー時間がかかった…。

というわけで、今度はgemini/cancerで共有しているディスクに、LVM構成とgfs2ファイルシステムを作成する。
この辺の内容で既に検証してるけど、今一度整理しよう。
当時の手順、間違いもあるから。

あと、サービスの導入やら起動やらを変更しているので、gemini/cancerとも再起動しておいた方が良いかな。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ systemctl status lvm2-cluster-activation.service
(cancer) $ systemctl status lvm2-cluster-activation.service

起動出来てなかった。
(gemini) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
              /etc/systemd/system/lvm2-cluster-activation.service
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
              /etc/systemd/system/lvm2-cluster-activation.service
(gemini) $ sudo vi /etc/systemd/system/lvm2-cluster-activation.service
--以下のように修正
After=lvm2-clvmd.service lvm2-cmirrord.service

#After=lvm2-clvmd.service lvm2-cmirrord.service
After=lvm2-clvmd.service
--ココまで
cancerも同様に修正しておく。

修正終わったら反映。
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl daemon-reload
(gemini) $ systemctl status lvm2-cluster-activation.service
(cancer) $ systemctl status lvm2-cluster-activation.service

これで起動してみる。
(gemini) $ sudo systemctl start lvm2-cluster-activation.service
やっぱり起動しない…。


まずは、VGの作成。
同じ仮想ディスクをgemini/cancerの両方に接続しており、いずれも/dev/vdbとして見えている。
(gemini) $ lsblk
(cancer) $ lsblk
これを使って作成していく。
(gemini) $ sudo pvcreate /dev/vdb
(gemini) $ sudo vgcreate vg-gfs2 /dev/vdb
(gemini) $ sudo vgdisplay vg-gfs2
(gemini) $ sudo lvcreate -L 10G -n lv-gfs2 vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
なぜか、意図的にクラスタマークを付与(vgchange -c y)しなくても、クラスタマークが付与された。

さて、LVまで作成できたので、今度はファイルシステムだ。
(gemini) $ sudo mkfs.gfs2 -j2 -p lock_dlm -t gfs2-cluster:fs-gfs2 /dev/vg-gfs2/lv-gfs2
-tオプションは、「クラスタ名」+「:」+「任意の名前」だ。
-jオプションはジャーナル数で、同時にマウントするノード数以上の数字を指定する必要がある。
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs2
(cancer) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs2

マウントできるのかな…?
(gemini) $ sudo mkdir /mnt/test
(gemini) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(gemini) $ df /mnt/test
(cancer) $ sudo mkdir /mnt/test
(cancer) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(cancer) $ df /mnt/test
マウントは出来た…。

読み書きテスト
(gemini) $ sudo bash -c "echo \"This is a test\" > /mnt/test/hoge"
(cancer) $ cat /mnt/test/hoge
出来た…。
lvm2-cluster-activation.service は必要無いのか?

一旦再起動して、再度マウントしてみるか…。
(gemini) $ sudo umount /mnt/test
(cancer) $ sudo umount /mnt/test
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(cancer) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(gemini) $ cat /mnt/test/hoge
(cancer) $ cat /mnt/test/hoge
(gemini) $ sudo umount /mnt/test
(cancer) $ sudo umount /mnt/test

確認ができたら、リソースを作成する。
(gemini) $ sudo pcs resource create cluster-gfs Filesystem \
    device="/dev/vg-gfs2/lv-gfs2" \
    directory="/mnt/test" \
    fstype="gfs2" \
    op monitor interval=10s on-fail=fence clone interleave=true
(gemini) $ sudo pcs resource show cluster-gfs
(cancer) $ sudo pcs resource show cluster-gfs
できてる。

(gemini) $ df
(cancer) $ df
両方ともマウントされている。

これでいいのか…?
おっと、リソースの起動順と、起動するノードを定義してなかった。
clvmdより後に起動させる必要があるため、それに従って設定する。
(gemini) $ sudo pcs constraint order start clvmd-clone then cluster-gfs-clone
(gemini) $ sudo pcs constraint colocation add cluster-gfs-clone with clvmd-clone
(gemini) $ sudo pcs constraint show cluster-gfs-clone
(cancer) $ sudo pcs constraint show cluster-gfs-clone

これでいいのだろうか?
一旦再起動仕掛けてみる。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
片方ずつ落としたらどうなる?
(gemini) $ sudo systemctl poweroff
(cancer) $ cat /mnt/test/hoge

どうやら上手く行っているようだ。
ちょっと時間がかかって、全体の流れがわかりにくくなったので、次回はgemini/cancerを作り直して、もう一度ゼロから実施してみることとする。

2019年2月16日土曜日

げ、stonith(fence)の設定が先だ(gfs2用)

RedHat社のサイトをよくよく読んでみると、「クラスターにはフェンシングを設定する必要があります」って書いてあった。
「いつフェンシング設定するんだろう?」って思ってたんだけど、実は先に設定する必要があったのね。

というわけで、fenceの設定を。

まずは、fence-agentsをインストールする。
(gemini) $ sudo apt-get install fence-agents
(cancer) $ sudo apt-get install fence-agents

で、フェンシングを設定するんだけど、どのフェンスデバイスがいいのか…。
(gemini) $ sudo pcs stonith list
gemini / cancer は kvm/libvirt で動かしているので、fence_virsh を使用するのがスジなんだけど…。
そもそも、今検証している gemini / cancer 環境は、物理マシン(sagittarius / aquarius)で正しく gfs2 を使用するための環境なので、物理マシンで使えるフェンスデバイスにする必要がある。
よく見てみたら、fence_scsi というタイプがある。これを使ってみよう。

とりあえず、gemini/cancer 両ノードで共有する1GBのディスクを追加しておく。
これをストレージフェンシングデバイスとして使用してみたい。

OSの再起動等をこなして、/dev/vdc として確認できたら、ストレージフェンシングデバイスを設定してみる。(できるのか?)
と思ったけど、ディスクデバイス側にpersistent reservationの機能が必要みたいで、virtoio 及び scsi passthrough では対応していないっぽい…。

となると、iSCSIデバイスを作ってみるのが正解か。
過去の記事などを参考に、gemini/cancerに1GBの共有iSCSI-LUNが接続されるようにしておく。
合わせて、/dev/vdc は解除しておこう。

で、色々試していってるんだが、どうやら /var/run/cluster/fence_scsi.key と /var/run/cluster/fence_scsi.dev という2つのファイルが必要っぽい。
ただ、/var/run は tmpfs なので、ココのファイルはOS再起動で消えてしまう。
自動で作ってくれる仕組みがあると思うんだが…。

とりあえず fence_scsi のフェンシングデバイスを作成する。
×(gemini) $ sudo pcs stonith create scsi-fence fence_scsi action=off devices=/dev/sda verbose meta provides=unfencing
(gemini) $ sudo pcs stonith create scsi-fence fence_scsi pcmk_host_list="gemini cancer" devices=/dev/sda verbose meta provides=unfencing
meta設定(provides=unfencing)は必要のようだ。

gemini で実行すれば、cancer 側からも確認できる。
(cancer) $ sudo pcs stonith show
 scsi-fence     (stonith:fence_scsi):   Stopped

デバイスとして指定した /dev/sda で、fence_scsi の情報を見てみる。
$ sudo fence_scsi -d /dev/sda -n gemini -o status -v
(略)
0   PR generation=0x0, there are NO registered reservation keys
No registration for key 2b4d0000 on device /dev/sda
Status: OFF

Status は OFF で、 PR の欄を見ると鍵情報が登録されていない。

gemini、cancer の両ノードで、鍵を登録してみる。
(gemini) $ sudo fence_scsi -o on -d /dev/sda -n gemini
(cancer) $ sudo fence_scsi -o on -d /dev/sda -n cancer

(gemini) $ sudo fence_scsi -d /dev/sda -n gemini -o status -v
0   PR generation=0x2, 2 registered reservation keys follow:
    0x2b4d0000
    0x2b4d0001
Status: ON

鍵情報が登録されて、Status が ON になった。

(gemini) $ sudo pcs stonith show
でも、まだ pacemaker 的には stop のままだ。

cleanup すればいいのだろうか…。
(gemini) $ sudo pcs stonith cleanup scsi-fence

実際には、色々試しているうちに動くところまで確認できた。
動き出したのはいいが、cancerで動いている。
(gemini) $ sudo pcs stonith show
 scsi-fence     (stonith:fence_scsi):   Started cancer

これはもしかして…。各ノードごとにフェンスの設定を入れて、自ノードでのみ稼働するように設定する必要があるのだろうか…。
#fence_virsh などはそのように定義する。2ノードクラスタなら良いのだが、3ノード以上のクラスタの場合はどうするんだろうか…?

やっぱりイマイチ分からん。
とりあえずこのまま進めていくか。

2019年1月19日土曜日

16.04のpacemakerのsystemd定義修正

どうにも挙動がよくわからないので色々調べてみたら、定義に問題がありそうだ…。
/lib/systemd/system/pacemaker.service を見ると、どうもRHEL系の定義っぽい。またパッケージミスかよ。ちなみに、18.04の同ファイルは、.deb系に書き換わっている様子。
ちょっと手直ししておこう。

sudo cp -pi /lib/systemd/system/pacemaker.service /etc/systemd/system/
sudo vi /etc/systemd/system/pacemaker.service
--ココから
23-24行目
EnvironmentFile=-/etc/sysconfig/pacemaker
EnvironmentFile=-/etc/sysconfig/sbd

EnvironmentFile=-/etc/default/pacemaker
EnvironmentFile=-/etc/default/sbd
--ココまで
sudo systemctl daemon-reload
sudo systemctl reboot

とりあえずこれでヨシ。

2019年1月6日日曜日

16.04のpacemakerどうもおかしい

16.04でpacemakerを動かそうと、色々調査を進めてるんだけど、どうもおかしい。
パッケージの内容がRHEL系っぽい。
で、18.04のpacemakerパッケージと比較してみたら、かなりガッツリ修正が入ってるわ。
16.04でpacemaker動かすの諦めて、18.04にバージョンアップしてからpacemaker動かすようにした方がいいのかなー??

でも、今のメインの環境(sagittarius/aquarius)は、過去に18.04にバージョンアップしたら、gfs2にアクセス出来なくなったしなー…。
どういう順番で作業すべきか…。

2019年1月2日水曜日

Ubuntu16.04のパッケージングミス?(/etc/corosync/uidgid.d/)

忙しくて全然進められなんだ…。
すでに18.04どころか18.10も出て、もうすぐ19.04も出るっていうのに…。

pcs config でエラーが出るんだけど、ちょっと確認してみたら /etc/corosync/uidgid.d/ というディレクトリが存在しないためのようだ。
18.04 の方は、corosyncパッケージに /etc/corosync/uidgid.d/ というディレクトリは含まれているが、16.04 の方には含まれていない。
それが原因っぽい。

ので、gemini / cancer でディレクトリ作っておく。
sudo mkdir /etc/corosync/uidgid.d/
sudo chmod 755 /etc/corosync/uidgid.d/
sudo chown root:root /etc/corosync/uidgid.d/
ls -ld /etc/corosync/uidgid.d/