cancer で multipath

次は multipath だ。
まだ cancer には iSCSI のボリュームは見えていないが、gemini と同じボリュームを同じように見えるようにするので、先に multipath を設定しておく。

(cancer) $ ls -ld /etc/multipath
(cancer) $ sudo mkdir /etc/multipath
(cancer) $ sudo chown root:root /etc/multipath
(cancer) $ sudo chmod 600 /etc/multipath
(cancer) $ ls -ld /etc/multipath

(cancer) $ ls /etc/multipath.conf
(cancer) $ sudo bash -c \
"zcat /usr/share/doc/multipath-tools/examples/multipath.conf.annotated.gz \
> /etc/multipath.conf"
(cancer) $ ls /etc/multipath.conf

(cancer) $ sudo vi /etc/multipath.conf
--ココから
10行目付近
#defaults {
↓先頭の#を削除
defaults {

215行目付近
# user_friendly_names no
↓先頭の#を削除し、no→yesへ書き換え
user_friendly_names yes

341行目付近
#}
↓先頭の#を削除
}
--ココまで
(cancer) $ sudo systemctl reload multipathd.service
(cancer) $ systemctl --no-pager -l status multipathd.service

先行して wwids ファイルと bindings ファイルは作ってしまおう。
中身は gemini のものと同じでいいので、gemini の中身を参考に。
(gemini) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo vi /etc/multipath/wwids
--gemini で確認した内容をそのまま書き込む

(cancer) $ sudo chmod 600 /etc/multipath/wwids

(gemini) $ sudo cat /etc/multipath/bindings
(cancer) $ sudo vi /etc/multipath/bindings
--gemini で確認した内容をそのまま書き込む

(cancer) $ sudo chmod 600 /etc/multipath/bindings

これで終わりかな？
後は iSCSIターゲットから LUN が見られるようになれば、自動的に multipath デバイスとして認識してくれるはずだ。

というわけで次回は iSCSIイニシエータかな？

/var/lib/libvirt の拡張

さて続いて、/var/lib/libvirt の領域の拡張方法を記載しておく。
LVMに詳しいのなら、特に気にしなくても大丈夫だ。

一つだけ注意点がある。
ext4 系のファイルシステムなら、一度拡張しても、縮小することは出来る。が、gfs2 ファイルシステムは一度拡張したら、縮小することが出来ない。拡張は簡単だが、縮小が出来ないため、拡張が必要な場合は十分に検討して拡張するように。

また、前回作成したVGは、わざと20GBほど残している。これは将来、このVGからスナップショットを作ることを想定してのことだ。LVMではボリューム管理が楽なので、わざと多少残しておいておくのがベターだぞ。

---

まずは、iSCSI領域から新しいLUN(100GB)を作成し、kvmtargetターゲットに接続しよう。
この時、LUNの名前は kvm002 にしておこう。(数が増えれば、当然末尾の数字は増やす。)

---

続いて、aquarius / sagittarius で iSCSI LUN の確認をしよう。
$ dmesg
aquarius では /dev/sdc、sagittarius では /dev/sdj として認識された。
(この辺は、マシンの環境でデバイス名が変わるぞ)

---

今度は、確認できたLUNを、multipath 管理下にする。
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdj
$ sudo cat /etc/multipath/wwids

bindings ファイルへ反映(下線部は、上記コマンドで見つかった wwid にすること)
$ sudo cat /etc/multipath/bindings
$ sudo bash -c "echo kvm002 23661323765323131 >> /etc/multipath/bindings"
$ sudo cat /etc/multipath/bindings

multipath コマンドで反映＆確認
$ sudo multipath -ll
(aquarius) $ sudo multipath -r /dev/sdc
(sagittarius) $ sudo multipath -r /dev/sdj
$ sudo multipath -ll

これで、追加ディスクを /dev/mapper/kvm002 として取り扱うことが出来るようになった。

---

次は LVM 関連の操作。
$ sudo pvdisplay /dev/mapper/kvm002
(aquarius) $ sudo pvcreate /dev/mapper/kvm002
$ sudo pvdisplay /dev/mapper/kvm002

$ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgextend kvmcluster /dev/mapper/kvm002
$ sudo vgdisplay -v kvmcluster

今回は、 /var/lib/libvirt 用に 100GB 拡張する。
(実際には、追加した 100GB の LUN は、LVM管理情報等が入るため、100GB から若干少ない容量になるのだが、あまり細かい計算はしない)
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt
(aquarius) $ sudo lvextend -L +100G kvmcluster/var-lib-libvirt
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt

$ sudo vgdisplay -v kvmcluster

これで、kvmcluster/var-lib-libvirt の領域が 180GB まで拡張されたはずだ。

---

今度は、ファイルシステムの拡張。
(aquarius) $ df -h /var/lib/libvirt
(aqaurius) $ sudo gfs2_grow -T /var/lib/libvirt
(aquarius) $ sudo gfs2_grow /var/lib/libvirt
(aquarius) $ df -h /var/lib/libvirt

この時、どうやら当該領域をマウントしている全てのノードで gfs2_grow を実施しないといけないようだ…。
今回は aquarius でしかマウントしていないため、特に気にする必要はなかった。
次回気をつけよう。

ファイルシステムのマウントはこれで一旦終了。
必要に応じてこの手順を繰り返して、必要量に拡張してくれ。

aquarius / sagittarius 用の共有ボリュームの作成

今度は、KVM の共有ボリュームの作成だ。
殆どは、これまで実施してきた作業の応用なので、そんなに説明はいらないだろう。

---

まずはストレージ装置で、iSCSIターゲットを新たに作成する。
名前は kvmtarget とでもしておこう。

---

で、aquarius / sagittarius からのみアクセス可能にする。(アクセス権限は R/W)
aquarius / sagittarius の iSCSIイニシエータのIQNが必要だが、それは /etc/iscsi/initiatorname.iscsi を見れば分かるぞ。
$ sudo cat /etc/iscsi/initiatorname.iscsi

---

そしたら、ストレージ装置側でボリュームを作成し、今作成した iSCSIターゲット へ割り当てよう。
LUNの作成方針としては、各自で自由に決めてもらっていいけど、自分は 100GB ずつ作成、という方針にしている。
まずは 100GB を1つ、kvm001 という名前で作成した。

---

この状態で、aquairus / sagittarius から iSCSIターゲット へログインする。
$ sudo iscsiadm -m discovery -t sendtargets -p (NASのIPアドレス)
$ sudo iscsiadm -m node --targetname (NASのIQN名) --login
(NAS の IQN名 は、ストレージ装置側で確認しよう。)

そうしたら、新たなディスクが見えてきたはずだ。
$ dmesg
(aquarius では /dev/sdc、sagittarius では /dev/sdi で見えてきた。)

合わせて、OS 起動時にiSCSIターゲットに自動的にログインするようにしよう。
$ sudo iscsiadm --mode node \
--targetname=(iSCSIターゲットのIQN名) \
--op=update \
--name=node.startup \
--value=automatic

---

このディスクを multipathd 管理にする。
$ lsblk
$ sudo multipath -ll
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdi
(aquarius / sagittarius どちらも同じ wwid が追加されたはず。)

$ sudo vi /etc/multipath/bindings
先程見えてきた wwid を、kvm001 という名前にする。
具体的には以下の行を追記する。(下線部は見えてきた wwid にすること)
kvm001 23565633034613838

multipathd でデバイスを認識する
$ sudo multipath -ll
$ sudo multipath -r
$ sudo multipath -ll
これで、/dev/mapper/kvm001 というデバイスファイル名でアクセス出来るようになるはずだ。

$ lsblk
mpath名 kvm001 が存在していることが確認できる。

---

続いて、そのボリュームを使って仮想マシン領域を作成する。
/etc/libvirt と /var/lib/libvirt の2つとし、/var/log/libvirt は OS ディスク領域をそのまま使うことにする。

また /etc/libvirt は、そんなに頻繁に書き換わるわけではないため、ジャーナルサイズはデフォルトの128MBから大きく下げて、最低の 8MByte にする。
2017/05/22 修正
ジャーナルサイズを最低の 8MByte にしたら、aquarius と sagittarius で同時マウントすることが出来なかった。原因は分からないが、デフォルトの 128MByte とする。
2017/05/22 修正ココまで

ディスクは、mbr/gpt パーティションを作らず、そのまま LVM-PV に使用する。

その他諸々の設定は、以下のコマンドから読み取ってくれぃ。

(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(aquarius) $ sudo pvcreate /dev/mapper/kvm001
(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(sagittarius) $ sudo pvdisplay /dev/mapper/kvm001

(aquarius) $ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgcreate -c y kvmcluster /dev/mapper/kvm001
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster

(aquarius) $ sudo lvcreate -L 32M -n etc-libvirt kvmcluster
2017/05/22 修正
ジャーナルサイズをデフォルトの 128MByte にする関係で、この領域のサイズは 32MByte では足りなくなる。そのため、1GByte にした。
(aquarius) $ sudo lvcreate -L 1G -n etc-libvirt kvmcluster
2017/05/22 修正ココまで
(aquarius) $ sudo lvcreate -L 80G -n var-lib-libvirt kvmcluster
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster

(aquarius) $ sudo lvchange -asy kvmcluster/etc-libvirt
(aquarius) $ sudo lvchange -asy kvmcluster/var-lib-libvirt

(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:etc-libvirt \
-p lock_dlm \
-J 8 \
-j 2 \
/dev/kvmcluster/etc-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt

(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:var-lib-libvirt \
-p lock_dlm \
-j 2 \
/dev/kvmcluster/var-lib-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt

---

領域を作ったら、今の仮想マシン環境情報を新しい領域に移し、マウントし直す。

(aquarius) $ sudo mkdir /mnt/libvirt

(aquarius) $ sudo mount /dev/kvmcluster/etc-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt

(aquarius) $ sudo -i
(aquarius) # cd /etc
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit

(aquarius) $ sudo umount /mnt/libvirt

(aquarius) $ sudo mount /dev/kvmcluster/var-lib-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt

(aquarius) $ sudo -i
(aquarius) # cd /var/lib
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit

(aquarius) $ sudo umount /mnt/libvirt

(aquarius) $ sudo rmdir /mnt/libvirt

/var/log/libvirt は、専用のボリュームを作らず、/var/log に配置する。
aquarius / sagittarius 両方で実施したいが、sagittarius 上では仮想マシンが稼働しているため、実施できない。
そのため、sagittarius 上では別途実施する。
(aquarius) $ cd /var/log
(aquarius) $ sudo tar cvf libvirt.tar libvirt
(aquarius) $ sudo systemctl stop /var/log/libvirt
(aquarius) $ sudo chmod 755 /var/log/libvirt
(aquarius) $ sudo chown root:root /var/log/libvirt
(aquarius) $ sudo tar xvf libvirt.tar
(aquarius) $ sudo rmdir libvirt/lost+found
(aquarius) $ ls libvirt
(aquarius) $ sudo rm libvirt.tar
(aquarius) $ cd

/etc/libvirt、/var/lib/libvirt のマウント情報を書き換え、/var/log/libvirt のマウント情報を削除する
(aquarius) $ sudo systemctl stop /etc/libvirt
(aquarius) $ sudo systemctl stop /var/lib/libvirt
(aquarius) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
↓
/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl start /etc/libvirt
(aquarius) $ grep /etc/libvirt /etc/mtab
(aquairus) $ sudo systemctl start /var/lib/libvirt
(aquarius) $ grep /var/lib/libvirt /etc/mtab

(aquarius) $ ls /etc/libvirt
(aquarius) $ ls /var/lib/libvirt

---

これで、共有領域の作成は完了だ。
(出来ればこのタイミングで、aquarius を再起動して、キチンとマウントされるか確認しておいたほうが良いが…。)

次は仮想マシンを共有領域へ移動、だが、その前に明らかに仮想ディスク領域( /var/lib/libvirt )が足りない。
その為、次回はまず、仮想ディスク領域を拡張する手順を作る。
＃コレ以降、仮想ディスク領域の拡張は、特に書かないツモリ…。

multipathd の導入

というわけで、sagittarius / aquarius に mutlipathd を導入する。
途中、OS再起動 / 仮想マシンディスク領域の再認識を行うので、ゲストは止めておこう。

ざっくり以下の手順だ。
まずはインストール。
(プロンプトの前にホスト名が書いていない行は、sagittairus / aquarius 両方で実施)
$ sudo apt-get update
$ sudo apt-get --simulate install multipath-tools
$ sudo apt-get install multipath-tools

$ ps -ef | grep multipath

$ ls -ld /etc/multipath
(ディレクトリが無ければリブートだが、今回は両ホストともディレクトリが作成された)

$ ls /etc/multipath.conf
$ cd /usr/share/doc/multipath-tools/examples
$ sudo bash -c "zcat multipath.conf.annotated.gz > /etc/multipath.conf"
$ ls /etc/multipath.conf
$ cd

$ sudo vi /etc/multipath.conf
--ココから
10行目付近
#defaults {
↓先頭の#を削除
defaults {

215行目付近
# user_friendly_names no
↓先頭の#を削除し、no→yesへ書き換え
user_friendly_names yes

341行目付近
#}
↓先頭の#を削除
}
--ココまで
$ sudo systemctl reload multipathd.service

ここで、open-iscsi.service の再起動を行い、使用中の関連ディスクの再認識をする。
(そのため、ゲストは停止しておくこと)
$ sudo systemctl restart open-iscsi.service

ココから、wwids ファイルに手を加えていくのだが、色々弄った関係で、sagittarius / aquarius で iSCSI LUN の数が異なっている。
最終的には統一させる予定だが、今は各ホストに合わせて実施していく。

sagittarius は、sdd / sde / sdf / sdg / sdh の 5LUN 持っている。
(sagittarius) $ sudo cat /etc/multipath/wwids
(sagittarius) $ sudo multipath -a /dev/sdd
(sagittarius) $ sudo multipath -a /dev/sde
(sagittarius) $ sudo multipath -a /dev/sdf
(sagittarius) $ sudo multipath -a /dev/sdg
(sagittarius) $ sudo multipath -a /dev/sdh
(sagittarius) $ sudo cat /etc/multipath/wwids

(sagittarius) $ sudo cat /etc/multipath/bindings
(sagittarius) $ sudo multipath -r /dev/sdd
(sagittarius) $ sudo multipath -r /dev/sde
(sagittarius) $ sudo multipath -r /dev/sdf
(sagittarius) $ sudo multipath -r /dev/sdg
(sagittarius) $ sudo multipath -r /dev/sdh
(sagittarius) $ sudo cat /etc/multipath/bindings

もう一度ディスクの再認識。
(いちいち再認識する必要無いはずなんだけど…)
(sagittarius) $ sudo systemctl restart open-iscsi.service
(sagittairus) $ sudo multipath -ll

aquarius は sdb の 1LUN のみだ。
(aquarius) $ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdb
(aquarius) $ sudo cat /etc/multipath/wwids

(aquarius) $ sudo cat /etc/multipath/bindings
(aquarius) $ sudo multipath -r /dev/sdb
(aquarius) $ sudo cat /etc/multipath/bindings

(aquarius) $ sudo systemctl restart open-iscsi.service
(aquarius) $ sudo multipath -ll

gemini / cancer の時はデバイスファイル名(mpath?)を変更したが、今回は変更しない。
後日、正規に iSCSI LUN を付けた時にはきちんと命名することにする。

あと、iSCSI のディスク領域(/etc/libvirt、/var/lib/libvirt、/var/log/libvirt がアンマウントされていると思うので、適宜マウントしておくこと。

次回からは、corosync / dlm / gfs2 の導入だ。

これまでを踏まえて、aquarius / sagittarius の手入れを

gemini / cancer を用いて、かなりの検証が出来た。
で、その内容はホストである aquarius / sagittarius に反映させておきたい。

一体いくつの変更/修正点があるのだろうか…

1. openvswitch の仮想スイッチ名の変更(br-external→extsw)
2. 自動起動ネットワークの手直し(/etc/default/networking)
3. OpenvSwitch と open-iscsi の起動停止順の制御
4. multipathd の導入
5. corosync / dlm / gfs2 の導入とセットアップ
6. CLVM の導入とセットアップ
7. 仮想マシン領域の gfs2 化

え？コレだけ？結構色々検証したと思ったけど、まとめてみるとこの程度か…。
結構時間がかかったんだな…。

というわけで、次回から上記に従って進めていくことにする。

シャットダウン時に刺さる現象(その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

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

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

ココで、「シャットダウン・リブート中に刺さったような現象が」って書いた。

コレ、どうやら iSCSIターゲットにログインしている状態(iSCSIディスクのLVMアクティベートは関係なく)でシャットダウンやリブートを行うと発生するようだ。
iSCSIターゲットからログアウトした状態でリブートした場合は発生しない。

ということは、ネットワーク切断後にiSCSIログアウトを行おうとしているんだろう。

今回の構成は、OpenvSwitchで作った仮想スイッチの先に iSCSIターゲットがあるが、普通に設計する場合は、iSCSI用に専用の物理ネットワークポートを用意(大抵は冗長化のため、複数ポート)する。
この場合、iSCSI専用NICには、OpenvSwitchのような仮想スイッチを挟むことはしないはずだ。

自宅で作っているような小さな環境の場合、データ用とiSCSI用でネットワークも分離せず、全て1系統のみで賄ってしまうような形になるだろう。
つまるところ、ウチの構成が、iSCSIターゲットを使う理想の構成からは外れている、ということだ。

恐らく、OpenvSwitchによる仮想スイッチの停止処理と、iSCSIターゲットからのログアウト処理の順序性の問題だと思われる。

となると、どうすればいいのだろうか？
そのあたりを中心に、ちょっと調査を継続しよう。

まずはiSCSIボリュームでocfs2/gfs2共有領域を

とりあえず、共有領域を作ろう。
以前、ココで100GBの ocfs2 用のボリュームは用意した。
とりあえず、コレを使って ocfs2 用の領域を作ろう。
multipath が正しく動いていれば、 /dev/mapper/ocfs2-001 というデバイスファイル名で見えているはずだ。(シンボリックリンクだけど、普通にデバイスファイルとして扱える。)

これを、クラスタマークを付与した /dev/vg-ocfs2 に追加し、既に存在するファイルシステムを pvmove で /dev/mapper/ocfs2-001 に移してしまう。

アクティベートされていないと思うので、アクティベートしておこう。
(gemini) $ sudo vgchange -asy vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2

/dev/mapper/ocfs2-001 を vg-ocfs2 に追加。
これまでは、parted による gptパーティション を作っていたが、今回はディスクデバイスごと追加してしまう。
(gemini) $ sudo pvcreate /dev/mapper/ocfs2-001
(gemini) $ sudo pvdisplay /dev/mapper/ocfs2-001
(gemini) $ sudo vgextend vg-ocfs2 /dev/mapper/ocfs2-001
(gemini) $ sudo vgdisplay -v vg-ocfs2

ここまで出来たら、cancer 側でも確認。
(cancer) $ sudo vgdisplay -v vg-ocfs2

ちょっと試しに、両ノードでマウントしておこう。
(gemini) $ sudo systemctl start /mnt/ocfs2
あ…あれ？マウント出来ねぇ…。
なんか、クラスタサービスがどうのこうの…

ヨクワカランが、o2cbサービスの再起動をしておく。
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo systemctl restart o2cb
(cancer) $ sudo systemctl restart o2cb
(gemini) $ sudo vgchange -asy vg-ocfs2

再びマウント
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2
(cancer) $ df /mnt/ocfs2

マウント出来ているのが確認できたら、vdb1 から ocfs2-001 へ移動。
(gemini) $ sudo pvmove /dev/vdb1 /dev/mapper/ocfs2-001
Cannot move in clustered VG vg-ocfs2, clustered mirror (cmirror) not detected and LVs are activated non-exclusively.
おや？どうやら、排他モードでアクティベートしていないと、pvmove は出来ないらしい。知らんかった。
(clusterd mirror というのを動かしておけばいいようだ。これも要調査だな。)

というわけで、一旦排他モードにする。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -an vg-ocfs2
(gemini) $ sudo vgchange -aey vg-ocfs2
(gemini) $ sudo systemctl start /mnt/ocfs2

そしたら今度こそ pvmove 。
(gmeini) $ sudo pvmove /dev/vdb1 /dev/mapper/ocfs2-001
う～ん。排他モードでないとダメなのかなぁ？他にやり方ありそうだけど…。

pvmoveが完了したら、状況を確認してみよう。
(gemini) $ ls /mnt/ocfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo pvdisplay -v /dev/vdb1
(gemini) $ sudo pvdisplay -v /dev/mapper/ocfs2-001
vgdisplayのタイミングで、vg構成のバックアップが行われたようだ。
本来なら、vgcfgbackup を実行する必要がありそうだな。(今回は自動で実行されたので不要だが)

cancer側でも確認。
(cancer) $ sudo vgcfgbackup vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo pvdisplay -v /dev/vdb1
(cancer) $ sudo pvdisplay -v /dev/mapper/ocfs2-001

/dev/vdb1 の Allocated PE がゼロになっているのが確認できたら、この /dev/vdb1 は不要になったので、vg-ocfs2 から切り離そう。
(gemini) $ sudo vgreduce vg-ocfs2 /dev/vdb1
(gemini) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2

/dev/vdb1 の PVヘッダ(pvcreate コマンドでディスク上に付けられる管理情報)も削除しておこう。
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo pvremove /dev/vdb1
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1

パーティションテーブルも削除。
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb rm 1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print

削除が終わったら、/dev/vdb 自体をOSから外してしまおう。
(gemini) $ ls -l /sys/block/vdb/device
virtio4 へのシンボリックリンクのようだ。
(gemini) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(gemini) $ ls -l /dev/vdb*
(gemini) $ lsblk

cancerも。
(cancer) $ ls -l /sys/block/vdb/device
こちらも virtio4 へのシンボリックリンクのようだ。
(cancer) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(cancer) $ ls -l /dev/vdb*
(cancer) $ lsblk

そしたら、virt-manager を使って、仮想マシン gemini/cancer から当該仮想ディスクを外しておこう。

あっと、vg-ocfs2 は今、排他モードになっているはず。
共有モードに切り替えておこう。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo vgchange -asy vg-ocfs2

マウント出来るか確認。
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2

構成をいじったので、再起動して反映されているか確認しておこう。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot

(gemini) $ lsblk
(cancer) $ lsblk
(gemini) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
ここまで問題なし。

(gemini) $ sudo vgchange -asy vg-ocfs2
(gemini) $ sudo systemctl start /mnt/ocfs2
やっぱりマウントで失敗する。どうやら、o2cb の起動処理に問題がありそうだ。
別途調査。
取り急ぎ、o2cb の再起動で逃げよう。
(gemini) $ sudo systemctl restart o2cb
(cancer) $ sudo systemctl restart o2cb

も一回マウント
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
マウント出来た。

これで、iSCSI共有領域のみで ocfs2 のファイルシステムを用意できた。
共有用に使ってて、この作業で切り離した ocfs2.qcow2 は、virt-manager を使って削除しておこう。
-------------------------------------------------------
続いて、gfs2 領域もiSCSI化してしまおう。
やり方はまったく同じ。

まずは、NASキットの iSCSI ターゲット機能を使って、gemini/cancerに100GBのLUNを渡す。(gemini/cancerの両方と接続しているiSCSIターゲットに、100GBのLUNを追加する。)

dmesg コマンドで確認すると、gemini では /dev/sdc、cancer では /dev/sdb として認識された。

というわけで、gemini から作業。
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo multipath -a /dev/sdc
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -r /dev/sdc
(gemini) $ sudo multipath -ll
(gemini) $ sudo vi /etc/multipath/bindings
--ココから
mpatha 23566633634646565
↓(新しく作成されたデバイスの名前を変更する。)
gfs2-001 23566633634646565
--ココまで
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -F /dev/sdc
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -r /dev/sdc
(gemini) $ sudo multipath -ll

これで、gemini では、新しいディスクは /dev/mapper/gfs2-001 というデバイスファイル名で扱えるようになった。

続いて、cancer 側で同じ作業。
(cancer) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo multipath -a /dev/sdb
(cancer) $ sudo cat /etc/multipath/wwids

(cancer) $ sudo vi /etc/multipath/bindings
--ココから
(1行追加。)
gfs2-001 23566633634646565
--ココまで
(cancer) $ sudo multipath -ll
(cancer) $ sudo multipath -r /dev/sdb
(cancer) $ sudo multipath -ll

そしたら、ocfs2 と同じように移動作業。
ocfs2 の時は、排他モードでアクティベートしてから実施したけど、非アクティベート状態で実施する。
ただし、まだクラスタマークが付与されてなかったと思うので、クラスタマークは付与しておく。
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2

(gemini) $ sudo vgchange -c y vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2

(gemini) $ sudo vgextend vg-gfs2 /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2

(gemini) $ sudo pvmove /dev/vdb1 /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
ここまでで移動は完了のはず。

移動完了したので、古い方のボリュームは切り離す。
(gemini) $ sudo vgreduce vg-gfs2 /dev/vdb1
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2

(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo pvremove /dev/vdb1
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1

(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb rm 1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print

(gemini) $ ls -l /sys/block/vdb/device
virtio4 へのシンボリックリンクのようだ。
(gemini) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(gemini) $ ls -l /dev/vdb*
(gemini) $ lsblk

(cancer) $ ls -l /sys/block/vdb/device
こちらも virtio4 へのシンボリックリンクのようだ。
(cancer) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(cancer) $ ls -l /dev/vdb*
(cancer) $ lsblk

そしたら、virt-manager を使って、仮想マシン gemini/cancer から当該仮想ディスクを外しておこう。

vg-gfs2 を共有モードでアクティベートして確認だ。
(gemini) $ sudo vgchange -a n vg-gfs2
(gemini) $ sudo vgchange -asy vg-gfs2

マウント出来るか確認。
(gemini) $ sudo systemctl start /mnt/gfs2
(cancer) $ sudo systemctl start /mnt/gfs2

構成をいじったので、再起動して反映されているか確認しておこう。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
あれ？ココで cancer のシャットダウン処理中に刺さる現象が…。
ネットワーク関連っぽいな。cifs マウントか iSCSI 関連が絡んでいそうだ。
これも要調査。
とりあえず、cancer は強制的に再起動させた。

(gemini) $ lsblk
(cancer) $ lsblk
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2

(gemini) $ sudo vgchange -asy vg-gfs2
(gemini) $ sudo systemctl start /mnt/gfs2
(cancer) $ sudo systemctl start /mnt/gfs2
マウント出来た。

これで、iSCSI共有領域のみで ocfs2 のファイルシステムを用意できた。
ocfs2 の時と同様、共有用に使ってて、この作業で切り離した gfs2.qcow2 は、virt-manager を使って削除しておこう。

さて、ココまでで iSCSI 領域の共有化が完成したが、問題が3点。

1. ocfs2ファイルシステムのマウントが出来ない
   (o2cb.service を再起動させることで処理可能)
2. 再起動時に刺さる現象がまだ解消できていない
   (ネットワークとネットワークストレージの関連か？)
3. CLVM共有モードで pvmove するためには、 clusterd mirror というのが必要

だ。
これらも調査を継続しないと…な…。

幾つか記事の修正を

結局、corosyncの起動失敗に関しては、結論が出なかった。
そのため、corosync/dlmとlibvirt関連、KVM関連、及びKVM/libvirtが使用するファイルシステムのマウントは、OS起動時ではなくOS起動後、手作業で実施することにしよう。

また、過去の記事もかなり誤りが見つかったので、この辺りの記事から見直して加筆修正する。
直接記事を加筆修正するので、一度確認してみて欲しい。
--2017/04/20追記ココから--
とりあえず記事を修正してみた。
まだ抜け漏れあるかもしれないけど、気付いたら追記していく。
--2017/04/20追記ココまで--

iSCSIでmultipath

さて、試してみたいことはたくさんある。
その内の1つが、iSCSIストレージでmultipathは使えるのか？だ。

ストレージ装置(SAN/iSCSI等)とサーバ間の接続を、冗長構成を考慮して複数のパスを用意した場合、ディスクデバイスが複数個に見えてしまう。
同一のディスクデバイスに対して、複数のデバイスファイルが見えてしまうと、管理上めちゃくちゃ面倒くさい。
同一のディスクデバイスに対して、1つの仮想デバイスファイルを用意して、ボリューム管理をそのデバイスファイルに対して行えるようにする、というのがmultipathだ。
下の図だと、パスが2系統有る。この場合、同一の領域(LUN)に対して、OSは2つのデバイスファイル(例えば、/dev/sdgと/dev/sdh)を作成する。
が、この両方を操作するのは面倒くさい。
multipathを使うと、これを1つの仮想デバイス(例えば、/dev/mapper/mpathc等)に紐付けられる。
ディスクに対する操作(parted等)は、その/dev/mapper/mpathcに対して行うことになる。

仕事では、FC接続の場合でこのmultipathを使うことは多かった。(iSCSIでmultipathは実装したことが無い。)

更に、ウチの環境ではiSCSIこそあれど、パスはシングルだ。
シングルパスの場合、multipathを用いるメリットは殆ど無いのだが、iSCSIでmultipathが使えるのかどうか、試してみたいと思っていた。

とりあえず、gemini/cancerというゲストマシンがあるので、この2つとiSCSIストレージを使って、iSCSIディスクが使えるように環境を整える。
手順は、「iSCSIを利用しようその1」等に従えばいい、はずだ。

今回は、iSCSIターゲットは1つで、そのiSCSIターゲットに対して、gemini/cancerともに接続出来るようにしておくよ。

1つだけLUN(100GB)を割り当てたら、/dev/sdaとして見えてきた。

gemini/cancerから、LUNが見える状態になったこと、iSCSIターゲットへの自動ログインが確認できたら、multipathを導入してみる。
(現時点では、LUN(/dev/sda)に対してパーティションの作成等は不要だ)
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-cache search multipath

multipath-toolsっぽいな。
(gemini) $ sudo apt-get --simulate install multipath-tools
(gemini) $ sudo apt-get install multipath-tools

cancerにも。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install multipath-tools

導入できたら、デーモンの確認。
(gemini) $ ps -ef | grep multipath
(cancer) $ ps -ef | grep multipath
/sbin/multipathdというデーモンが動きだしたはず。

syslog見てみよう。
(gemini) $ tail -30 /var/log/syslog
エラーは特に無さそうだ。

が、multipathデバイスが出来ている様子が無い…。
多分、再起動しても無駄だと思うが…。
(gemini) $ sudo shutdown -r now

げ、再起動したら/etc/multipathディレクトリが出来上がったよ…。再起動必要なんかい！？
その中には、wwidsというファイルが出来上がっているが、中身は空(コメントのみ)。

それ以前に、multipath.confが必要なはずなんだが…。Ubuntuでは用意されてないのかな…。
(gemini) $ dpkg -L multipath-tools
サンプルっぽいのが2つある。
/usr/share/doc/multipath-tools/examples/multipath.conf.annotated.gz
/usr/share/doc/multipath-tools/examples/multipath.conf.synthetic

どちらも中身はすべて#で始まる無効行だが、前者の方がコメントがしっかり書かれている。
こちらを/etcの下に展開してしまおう。
(gemini) $ ls /etc/multipath.conf
(gemini) $ cd /usr/share/doc/multipath-tools/examples
(gemini) $ sudo bash -c "zcat multipath.conf.annotated.gz > /etc/multipath.conf"
(gemini) $ ls /etc/multipath.conf
(gemini) $ cd

(gemini) $ sudo systemctl daemon-reload
う～ん。まぁ中身が全部コメントだったから、何も変化は無いよな。

ちょっとmultipathの結果を見てみよう。
(gemini) $ sudo multipath -v 3
以下のような行が出た…。
wwid 23966323038343131 not in wwids file, skipping sda
この、239...という数字は、/dev/disk/by-id/ の中で/dev/sdaにリンクが貼られているファイルの名前と同じだ。
つまり、このディスク(/dev/sda)のuuid/wwidってことだよな…。

そして、not in wwids fileということは、逆に言うとwwidsファイルに記載したら何か起きるのか？

書き込んでみよう。
なんか、wwidsファイルにwwidを書く時は、/で囲わないといけないっぽい。
(gemini) $ sudo bash -c "echo /23966323038343131/ >> /etc/multipath/wwids"
(gemini) $ sudo cat /etc/multipath/wwids

(gemini) $ sudo multipath -v 3
お、変化が出た。
色々メッセージが出たけど、その中に
create: 23966323038343131 undef ASUSTOR,iSCSI Storage
というのが出てきた。

これは…
(gemini) $ sudo multipath -ll
23966323038343131 dm-2 ASUSTOR,iSCSI Storage
size=100G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
`- 8:0:0:0 sda 8:0 active ready running
出来てる！

(gemini) $ ls -l /dev/mapper
数字の羅列のデバイスファイルが出来上がってるぞ。

これ、ディスク操作とかに使えるのかな？
(gemini) $ sudo parted /dev/mapper/23966323038343131 print
出来た。

しかしこれではちょっと見にくい。
なにせ名前が数字の羅列だ。
というわけで、分かりやすい名前に変更する方法を確認。
multipath.confのuser_friendly_nameというのが該当の設定項目だ。
さっそく変更しよう。
(gemini) $ sudo vi /etc/multipath.conf
--ココから
10行目付近
#defaults {
↓先頭の#を削除
defaults {

215行目付近
# user_friendly_names no
↓先頭の#を削除し、no→yesへ書き換え
user_friendly_names yes

341行目付近
#}
↓先頭の#を削除
}
--ココまで

設定の再読込み
(gemini) $ sudo systemctl reload multipathd.service

確認
(gemini) $ sudo multipath -ll
mpatha (23966323038343131) dm-2 ASUSTOR,iSCSI Storage
size=100G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
`- 8:0:0:0 sda 8:0 active ready running
mpathaと表示された！

(gemini) $ ls -l /dev/mapper
数字のデバイスファイルが消えて、mpathaが作成された。

(gemini) $ sudo parted /dev/mapper/mpatha print
ディスク認識OK。

(gemini) $ sudo cat /etc/multipath/bindings
wwidsとmpathaを紐付けるファイルが出来上がっている。

(gemini) $ lsblk /dev/sda
sdaからmpathaが作られている、ということが分かる。

これで最低限の設定は出来た。
パフォーマンスチューニング等、/etc/multipath.confを手直しすることになるんだけど、そこまで実施はしない。
(本当に複数パスで繋いでいる場合、パス分散ルールを変えることでパフォーマンス向上が期待できるけど、自分の構成ではシングルパスでしか繋いでいないので意味が無い…。)

さて、もう1つだけ実験しておこう。
デバイス名が/dev/mapper/mpathaになったけど、この名前を変更できるのだろうか？
なんとなく、/etc/multipath/bindingsファイルを書き換えれば実現できそうだ。
試してみよう。
(gemini) $ sudo vi /etc/multipath/bindings
以下のように修正
--ココから
mpatha 23966323038343131
↓
ocfs2-001 23966323038343131
--ココまで
今回、iSCSIストレージ装置側で作成した100GBのLUNの名前を、ocfs2-001としておいた。
サーバ側でも同じ名前だと管理が楽かもしれない。
ということでこの名前が使えるかを試してみる。

変更したら、一旦マルチパスデバイスを消して…
(gemini) $ sudo multipath -F /dev/sda
(gemini) $ sudo multipath -ll
消えたのを確認したら、デバイス再読込み…
(gemini) $ sudo multipath -r /dev/sda
で、ocfs2-001という名前で作られるようだ。

(gemini) $ sudo multipath -ll
出来上がった。

念のためデバイスファイルの確認
(gemini) $ ls -l /dev/mapper
ocfs2-001に変わっている。

ディスク確認
(gemini) $ sudo parted /dev/mapper/ocfs2-001 print
きちんと読み込める。(パーティション情報が一切ないので、ラベルが認識できない等のエラーになるが、無視してOK。)

さて、途中からgeminiにのみ設定を施していたので、cancer側も同じ設定を施しておく。
geminiとは若干順番が変わっているが気にしないでいい。

まずはmultipath.confファイルの作成。
(cancer) $ ls /etc/multipath.conf
(cancer) $ cd /usr/share/doc/multipath-tools/examples
(cancer) $ sudo bash -c "zcat multipath.conf.annotated.gz > /etc/multipath.conf"
(cancer) $ ls /etc/multipath.conf
(cancer) $ cd

multipath.confのカスタマイズ
(cancer) $ sudo vi /etc/multipath.conf
--ココから
10行目付近
#defaults {
↓先頭の#を削除
defaults {

215行目付近
# user_friendly_names no
↓先頭の#を削除し、no→yesへ書き換え
user_friendly_names yes

341行目付近
#}
↓先頭の#を削除
}
--ココまで
(cancer) $ sudo systemctl reload multipathd.service

まだwwidsファイルは出来上がってないと思うので、一旦OS再起動。
(cancer) $ sudo shutdown -r now

wwidsファイル変更(geminiの時は直接編集したが、今回はmultipathコマンドで編集)
(cancer) $ ls -ld /etc/multipath
(cancer) $ sudo ls -l /etc/multipath
(cancer) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo multipath -a /dev/sda
(cancer) $ sudo cat /etc/multipath/wwids

multipathデバイスの認識。
(cancer) $ sudo multipath -ll /dev/sda
(cancer) $ sudo multipath -r /dev/sda
(cancer) $ sudo multipath -ll /dev/sda

デバイスファイル名の修正
(cancer) $ sudo vi /etc/multipath/bindings
以下のように修正
--ココから
mpatha 23966323038343131
↓
ocfs2-001 23966323038343131
--ココまで

(cancer) $ sudo multipath -ll /dev/sda
(cancer) $ sudo multipath -F /dev/sda
(cancer) $ sudo multipath -ll /dev/sda
(cancer) $ sudo multipath -r /dev/sda
(cancer) $ sudo multipath -ll /dev/sda

とりあえず、これでiSCSIボリュームをmultipathd管理にすることは完了。