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