iSCSI領域をローカルマウントする時の注意

前回、ディスク構成を変更すると書いたけど、そこでちょっと問題が発生した。
iSCSIでLUNを作成し、LVM構成を組んでファイルシステム作成、ローカルマウントする、という流れだけど、これが上手く行かなかった。

具体的には、LVM VGの自動アクティベートが成功しない、もっと細かく書くと、7つのLUNのうち、1つ目のLUNのみ認識されている状態でアクティベートしようとしてしまい、中途半端な状態のアクティベートになってしまう、というもの。

どうやらOS起動時の流れが、OS LVMアクティベート→ネットワーク有効化→iSCSI有効化→他のLVMアクティベート、という順番のようで、iSCSI有効化後、iSCSIディスクを認識する処理と、LVMアクティベートの処理が並行してしまうようだ。
それが原因で、iSCSI領域のLVMアクティベートが失敗してしまう。

自動アクティベーションの対象は、/etc/lvm/lvm.conf に記載されている。
このファイルの auto_activation_volume_list に定義されている VG は、PV を認識したら自動でアクティベートしてしまう。
今回、iSCSIディスク7つのLUNで1つのVGを構成しているが、1つ目を認識した時点でアクティベーションしようとしてしまうようだ。

auto_activation_volume_list は初期値は未設定。
未設定というのは、全てのVGを自動アクティベーションする、ということ。
そのため、iSCSI LUNの認識が中途半端な状態でアクティベーションが走ってしまっていた。

そのため、iSCSIで作っているVGを、この自動アクティベートから外し、LUN全部認識した後にアクティベートするように手を加えたい。

まずは /etc/lvm/lvm.conf の auto_activation_volume_list を以下のように書き換える。
auto_activation_volume_list = [ "vg-root", "kvmcluster" ]
1つ目のパラメータはOS用のvg名、2つ目のパラメータはaqauariusとの共有VG名。
一瞬、2つ目のパラメータは不要だと思えるが、ここに入れておかないとclvmdを起動したときにkvmclusterがアクティベートされない。
クラスタの方で、dlm→clvmd→マウント という流れでresourceを作成した場合、auto_activation_volume_listにkvmclusterを入れていないと、マウントのタイミングでkvmclusterがアクティベートされず、マウントに失敗する。
ocf:heartbeat:LVM もしくは ocf:heartbeat:LVM-activate というリソースエージェントを間に挟めば、vg/lv単位でのアクティベート・ディアクティベートをクラスタで制御できるみたいだが、現時点ではそれが入っていない。
そのため、一旦はauto_activation_volume_listに"kvmcluster"を入れておく。

また、先日気づいたんけど /etc/lvm/lvm.conf を書き換えた場合、どうやら initramfs を再構築しないと、OS起動時の処理には反映されないようだ。
そのため、initramfs を再構築する。
$ sudo update-initramfs -u
これで再起動すれば、iSCSI LUN で作成したローカル用の VG はアクティベートされないはずだ。

続いて、iSCSI LUN 認識後に、ローカル用の VG をアクティベートする処理を入れる。
systemd で実現するが、少しずつ systemd に慣れてきて、ようやくそれなりに処理できるようになってきた。
細かい説明は省くが、以下の3つのファイルを作成する。

/etc/systemd/system/iscsi-after.service
--ココから
[Unit]
Description=wait at iscsi
After=open-iscsi.service multipathd.service

[Service]
ExecStart=/bin/sleep 10
Type=oneshot

[Install]
WantedBy=multi-user.target
--ココまで

/etc/systemd/system/vg-before.service
--ココから
[Unit]
Description=before vgchange
After=iscsi-after.service
Requires=iscsi-after.service

[Service]
ExecStart=/bin/true
Type=oneshot
RemainAfterExit=yes
--ココまで

/etc/systemd/system/vgchange@.service
--ココから
[Unit]
Description=vgchange -a [yn] %I
After=vg-before.service
Requires=vg-before.service
Before=libvirtd.service

[Service]
ExecStart=/sbin/vgchange -a y %I
Type=oneshot

[Install]
WantedBy=multi-user.target
--ココまで

2つ有効にする(もしかしたら、iscsi-after.service の有効化は不要かもしれない)
$ sudo systemctl daemon-reload
$ sudo systemctl enable iscsi-after.service
$ sudo systemctl enable vgchange@kvmsagi.service
(アンダースコアの kvmsagi の部分は、iSCSI領域で作った VG 名だ。変な名前だが、 sagittarius 専用の kvm 領域という名前を付けている)

ちなみに、sagittarius 専用の iSCSI 領域は、以下の2つの LV で構成されている。

• /dev/kvmsagi/etc-libvirt
• 4MB
• ext4
• /dev/kvmsagi/var-lib-libvirt
• 数百GB
• ext4

続いて、fstab を修正する
$ sudo vi /etc/fstab
--/etc/libvirt と /var/lib/libvirt のマウントを、以下のように修正する
/dev/kvmsagi/etc-libvirt /etc/libvirt ext4 noauto,_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.device-timeout=60 0 0
/dev/kvmsagi/var-lib-libvirt /var/lib/libvirt ext4 noauto,_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=60,x-systemd.device-timeout=60 0 0
--

これで再起動すれば、sagittarius 専用の iSCSI 領域がアクティベートされ、/etc/libvirt と /var/lib/libvirt にマウントされるはずだ。

ちょっと今回は詳細まで踏み込んでおらず、中身の説明も全然足りていない。
興味があったら調べてみてほしい。

KVMクラスタとストレージ

色々あってかなり間が開いてしまった。
その間も色々調査していたんだけど、構成が根本的にマズいということが分かった。
クラスタを組んで、gfs2による共有ファイルシステムをマウントするのなら、その領域は/var/lib/libvirt以外にしておくべきだった。
/var/lib/libvirtはローカルディスクにしておいて、共有ファイルシステムは別の領域にマウントする。
ただし、sagittarius/aquarius共に内蔵ディスクは容量が少ないため、専用領域を確保する余裕がない。
そこで、iSCSIターゲットを今までのsagittarius/aquarius共用とは別に、sagittarius専用、aquarius専用の2つを作成、それぞれLUNをアサインする形にする。

図.1

細かな作業手順は今回省略するが、過去の手順を元に実施して欲しい。

ただし、ローカルマウントの領域は、fstabによる直接マウントでも、automountdによる自動マウントでもなく、systemdによる自動マウントにする。

その手順は別途記載することにする。

リソースが起動しない

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