2017年5月2日火曜日

シャットダウン時に刺さる現象(その2)

調べてみると、iSCSIターゲットにログインする処理は、open-iscsi.service というサービスが担っているようだ。
(cancer) $ systemctl --no-pager -l status open-iscsi.service

更に、このサービスの停止処理を追いかけていくと、どうやら iSCSI領域のファイルシステムアンマウントも実行している模様。
実際に、iSCSI領域をマウントしている状態で、このサービスの停止を仕掛けてみると、ファイルシステムのアンマウントやiSCSIターゲットからのログアウトも自動的にやってくれている。

ということは、このサービスの前提に、openvswitch-switch.service を付けてやればいいんじゃないか?
というわけで試してみる。
(cancer) $ cd /lib/systemd/system
(cancer) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(cancer) $ sudo vi open-iscsi.service
--ココから
Wants=network-online.target remote-fs-pre.target iscsid.service
After=network-online.target iscsid.service
↓(前提条件に openvswitch-switch.service を追加)
Wants=network-online.target remote-fs-pre.target iscsid.service openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで
(cancer) $ cd

設定を読み込み
(cancer) $ sudo systemctl daemon-reload

ディスク類をマウントしてしまおう。
(まだ、o2cbの問題は解決していないので、o2cbの再起動も実施)
(cancer) $ sudo systemctl restart o2cb.service
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo vgchange -asy vg-gfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2

ここで再起動を実施するんだけど、刺さったかどうかはコンソールを見ておく必要がある。
virt-viewerを使って、コンソールから再起動させよう。
(cancer) $ sudo systemctl reboot

あれ?刺さった。
--------------------------------------------------------------------------------
どうやら、刺さる要因は2つあったようだ。

1つは「iSCSIターゲットからログアウトする前に、OpenvSwitchが停止してしまう」という現象。
こちらは、上で対処済み。

もう1つは ocfs2 絡みのようだ。
どうも絞り込んでいくと、ocfs2 ファイルシステムがマウントされている時に刺さる現象が起きているようだ。
ocfs2 ファイルシステムのアンマウントに時間がかかっていることが原因じゃないだろうか?
どうする?gfs2 が使えるので、ocfs2 は使わないようにすればいいのだが…。一応、もう少し調べてみよう。(o2cbサービスが正常起動出来ない点も含めて)

ちなみに、今KVMホストとして使っている aquarius/sagittarius は、ocfs2 関連の環境は一切作っていないため、刺さる現象は OpenvSwitch + iSCSI によるモノだ。

色々試してみたが、以下の組み合わせの時に発生するようだ。
  • OpenvSwitch を使用
  • OpenvSwitch の仮想スイッチを経由した iSCSI LUN
  • その LUN を multipathd でデバイスマッピング
  • そのデバイスマッピングで ocfs2 ファイルシステムを使用
  • そのファイルシステムをマウント
これらの条件が1つでも外れていると、再発しない様子。

どうも、iSCSIターゲットからログアウトする前に、OpenvSwitch が停止しているように見える。
もしそうだとしたら、gfs2 でも同じ事象が起きそうなものだが、gfs2 では同じ事象は発生しない。
これは、gfs2 / ocfs2 のアンマウントにかかる時間が違うからのようだ。
gfs2 は一瞬でアンマウントされるが、 ocfs2 はアンマウントに時間がかかる。
どうもそれが原因のようだ。

さてどうしよう。選択肢は2つ。
  • もっと原因と対策を追求する
  • ocfs2 を捨てる
出来れば、原因と対策を見つけ出した上で、ocfs2 を捨てて gfs2 オンリーにする、という形にしたい。今はまだ gfs2 では現象発生していないけど、gfs2 で発生する可能性もあるからだ。

というわけで、もう少し調査…。

色々調べていった結果、 lvm2-cluster-activation.service の停止処理に sleep を入れることで、再発率が大幅に下がることが分かった。
20秒の sleep で再現せず、5秒の sleep では時々再発。10秒の sleep で再現性がほぼ無くなったようだ。
ちょっと原因は分からないが、とりあえずこれで逃げることにしよう。

(cancer) $ cd /lib/systemd/system
(cancer) $ sudo vi lvm2-cluster-activation.service
--ココから
[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload

これでヨサゲ。

ついでに、 openvswitch-switch.service の起動時の処理に6秒の sleep を入れていたが、これも 10秒程度に延ばしておいた方が良さそうだ。
どうも、ウチの NAS の性能が良くなく、 iSCSI ログイン/ログアウトに(少し)時間がかかるのが直接の原因じゃないか?という疑い。
合わせて修正しておこう。

(cancer) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6

ExecStart=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload

これでとりあえず大丈夫だろう。
詳細がつかめたら、合わせて本対処するが、原因不明のため、このまま行くことにする。

0 件のコメント:

コメントを投稿