pacemaker検証(古い環境の削除)

というわけで、これまで作った検証環境のうち、今回のpacemakerで使用する環境を一旦全て削除する。

• pisces
• aries
• gemini
• cancer
• leo
• virgo

だ。
併せて、NASキット側でgemini/cancer向けに作成したiSCSIターゲット、iSCSI LUNも削除してしまう。
一旦キレイに作り直して置きたいからだ。

cancer で iscsi initiator

さて、iSCSI イニシエータだ。
まずは、open-iscsi.service の起動停止順を制御しておこう。

(cancer) $ sudo cp -pi /lib/systemd/system/open-iscsi.service \
    /lib/systemd/system/open-iscsi.service.orig
(cancer) $ sudo vi /lib/systemd/system/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
Wants=openvswitch-switch.serivce
After=network-online.target iscsid.service
After=openvswitch-switch.service
--ココまで

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

この時点で OS 再起動して、問題ないか確認しておきたい。
(cancer) $ systemctl status
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status open-iscsi.service

そうしたら、新 cancer の iqn名を確認。
(cancer) $ sudo cat /etc/iscsi/initiatorname.iscsi

NAS(iSCSIターゲット)側のアクセス許可を修正し、旧 cancer の iqn名を削除、今確認した新 cancer の iqn名からのアクセスを許可しよう。

そこまで実施できたら cancer から iSCSIターゲットへログインだ。
(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSI ターゲット名) \
--portal (NASのIPアドレス):3260 \
--op new
(3260 は NAS の iSCSIポートだ。デフォルトなら3260 のはず。)

(cancer) $ sudo iscsiadm --mode session
(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSI ターゲット名) \
--login
(cancer) $ sudo iscsiadm --mode session
ログインしただろうか？

ログインできたら、iSCSI の LUN が見えてきたはずだ。
(cancer) $ dmesg
(cancer) $ lsblk
(cancer) $ sudo multipath -ll

とりあえず、iSCSIターゲットへのログインを自動ログインにする。
(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSIターゲット名) \
--op show
node.startup が manual になっていることを確認。

(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSIターゲット名) \
--op update \
--name node.startup \
--value automatic

(cancer) $ sudo iscsiadm --mode node \
--targetname (iSCSIターゲット名) \
--op show
node.startup が automatic に変化しただろうか。

ココまで来たら、共有VG をアクティベートしてみよう。
(cancer) $ lsblk
(cancer) $ sudo vgchange -asy vg-gfs2
おや、どうやら出来ない。

何となく、dlm がこのボリュームを認識してないことが原因な気がする。
一度、dlm を再起動してみる。
(cancer) $ sudo systemctl restart dlm.service
(cancer) $ lsblk
お、LVを認識したぞ。

マウント云々は次回に回して、まずはキチンと再起動が出来るか確認だ。
(cancer) $ systemctl status
(cancer) $ sudo systemctl reboot
(cancer) $ dmesg
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status open-iscsi.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status corosync
(cancer) $ systemctl --no-pager -l status dlm
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls
(cancer) $ sudo vgdisplay -v vg-gfs2

どうやら問題無さそうだ。
次回はファイルシステムマウントかな？

使わなくなった iSCSI ボリュームの整理(sagittarius)

さて、最後に sagittarius だ。
こちらは調べてみたら、5LUNも未使用のディスクがある。

削除対象を、各レイヤーごとに記載しておく。
LVM

• vg-kvm/lv-etc-libvirt
• vg-kvm/lv-var-lib-libvirt
• vg-kvm/lv-var-log-libvirt

gpt

• /dev/mapper/mpatha-part1
• /dev/mapper/mpathb-part1
• /dev/mapper/mpathc-part1
• /dev/mapper/mpathd-part1
• /dev/mapper/mpathe-part1

multipath

• /dev/mapper/mpatha
• /dev/mapper/mpathb
• /dev/mapper/mpathc
• /dev/mapper/mpathd
• /dev/mapper/mpathe

scsi-disk

• /dev/sdj
• /dev/sdm
• /dev/sdn
• /dev/sdk
• /dev/sdl

さて、順番に削除だ。
(sagittarius) $ sudo vgchange -a n vg-kvm
(sagittarius) $ sudo lvremove vg-kvm/lv-etc-libvirt
(sagittarius) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(sagittarius) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(sagittairus) $ sudo vgremove vg-kvm
(sagittarius) $ sudo pvremove /dev/mapper/mpatha-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathb-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathc-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathd-part1
(sagittairus) $ sudo pvremove /dev/mapper/mpathe-part1
(sagittarius) $ sudo pvs
(sagittarius) $ sudo vgs
(sagittarius) $ lsblk

(sagittarius) $ sudo parted /dev/mapper/mpatha rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathb rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathc rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathd rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathe rm 1
(sagittarius) $ lsblk
あり？パーティション情報が消えてくれない。
でも、実際に parted で見ると消えてる。まぁいいや。

(sagittarius) $ sudo multipath -ll
(sagittarius) $ sudo multipath -f /dev/mapper/mpatha
(sagittarius) $ sudo multipath -f /dev/mapper/mpathb
(sagittarius) $ sudo multipath -f /dev/mapper/mpathc
(sagittarius) $ sudo multipath -f /dev/mapper/mpathd
(sagittarius) $ sudo multipath -f /dev/mapper/mpathe
(sagittarius) $ sudo multipath -ll

(sagittarius) $ sudo multipath -w /dev/sdj
(sagittarius) $ sudo multipath -w /dev/sdm
(sagittarius) $ sudo multipath -w /dev/sdn
(sagittarius) $ sudo multipath -w /dev/sdk
(sagittarius) $ sudo multipath -w /dev/sdl

(sagittarius) $ sudo vi /etc/multipath/wwids
(コメントになっているデバイス行を削除)
(sagittarius) $ sudo vi /etc/multipath/bindings
(mpatha,mpathb,mpathc,mpathd,mpatheを削除)

(sagittarius) $ sudo multipath -ll

(sagittarius) $ lsblk
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdj/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdm/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdn/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdk/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdl/device/delete"
(sagittarius) $ lsblk

ココからは iSCSI 関連だ。
(sagittarius) $ iscsiadm --mode session
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--logout
(sagittarius) $ iscsiadm --mode session

(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup

(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op update \
--name node.startup \
--value manual
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup

(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op delete
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup

iSCSI ストレージ側で不要な LUN、ターゲットの削除を行う。

最後に、念のために設定の再読み込み。(多分不要)
(sagittarius) $ sudo systemctl daemon-reload

これでオシマイ。だいぶすっきりした。
OS 再起動させたいところだけど、仮想マシンがガリガリ動いているので再起動しないでこのまま放置する。

使わなくなった iSCSI ボリュームの整理(gemini)

前回の続き。
sagittarius で実施する前に、 gemini の方で実施することにする。

流れとしてはほぼ同じだけど、gemini はまだ /var/log/libvirt が iSCSI ボリューム上に存在している。
これをローカルに移す作業が必要だ。

とは言え、過去に何度も実施したことのある手順なので、サクッと実施する。
(gemini) $ cd /var/log
(gemini) $ sudo tar cvf /tmp/libvirt.tar libvirt
(gemini) $ sudo systemctl stop /var/log/libvirt
(gemini) $ mountpoint /var/log/libvirt
(gemini) $ sudo tar xvf /tmp/libvirt.tar
(gemini) $ sudo rmdir /var/log/libvirt/lost+found
(gemini) $ sudo rm /tmp/libvirt.tar
(gemini) $ sudo vi /etc/fstab
(/var/log/libvirt のマウントエントリを無効化する）
(gemini) $ sudo systemctl daemon-reload
(gemini) $ cd
これで、ボリュームが1つ削除出来るようになったはずだ。

また、現在未使用な領域で、fstab 上にエントリが残っているものとして、ocfs2 の領域(/mnt/ocfs2)と、gfs2テスト領域(/mnt/gfs2)がある。
こちらも、もう使うことが無いので、/etc/fstab からエントリを消しておこう。
(gemini) $ sudo vi /etc/fstab
(/mnt/ocfs2 と /mnt/gfs2 のマウント情報を削除)
(gemini) $ sudo systemctl daemon-reload

そしたら、不要な領域を削除していこう。
(gemini) $ lsblk
(gemini) $ sudo lvs
確認すると、

• /dev/sda → /dev/mapper/ocfs2-001 → /dev/vg-ocfs2/lv-ocfs2
• /dev/sdb → /dev/sdb1 → /dev/vg-kvm(3LV全て)
• /dev/sdc → /dev/mapper/gfs2-001 → /dev/vg-gfs2/lv-gfs
• /dev/sdc → /dev/mapper/gfs2-001 → /dev/vg-gfs2/backup(ココで作成したバックアップ用領域)

あたりが不要のようだ。

LVM操作前に、/etc/lvm/lvm.conf で自動アクティベートになっていないか確認し、必要なら削除しておく。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近の以下の行を削除する
        auto_activation_volume_list = [ "gemini-vg", "vg-kvm", "vg-gfs2" ]
--ココまで

不要な領域を一つずつ削除していく。
(gemini) $ sudo lvremove vg-ocfs2/lv-ocfs
(gemini) $ sudo vgremove vg-ocfs2

(gemini) $ sudo vgchange -a n vg-kvm
(gemini) $ sudo lvremove vg-kvm/lv-etc-libvirt
(gemini) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(gemini) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(gemini) $ sudo vgremove vg-kvm

(gemini) $ sudo lvchange -a n vg-gfs2/lv-gfs
(gemini) $ sudo lvremove vg-gfs2/lv-gfs
(gemini) $ sudo lvchange -a n vg-gfs2/backup
(gemini) $ sudo lvremove vg-gfs2/backup

(gemini) $ lsblk
(gemini) $ sudo pvremove /dev/mapper/ocfs2-001
(gemini) $ sudo pvremove /dev/sdb1
(gemini) $ lsblk

(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo parted /dev/sdb rm 1
(gemini) $ sudo parted /dev/sdb print

LVM 情報が整理出来たら、次は multipath 関連だ。
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -f /dev/mapper/ocfs2-001
(gemini) $ sudo multipath -ll

(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo cat /etc/multipath/bindings
(gemini) $ sudo multipath -w /dev/sda
(gemini) $ sudo cat /etc/multipath/bindings
(gemini) $ sudo cat /etc/multipath/wwids

(gemini) $ sudo vi /etc/multipath/wwids
(コメント化された行を削除する。)
(gemini) $ sudo vi /etc/multipath/bindings
(ocfs2-001 の行を削除する。)

multipath の整理が終わったら、デバイスの削除。
(gemini) $ lsblk
(gemini) $ sudo bash -c "echo 1 > /sys/block/sda/device/delete"
(gemini) $ sudo bash -c "echo 1 > /sys/block/sdb/device/delete"
(gemini) $ lsblk

iSCSI ターゲットは2つ繋いでいるが、そのうちの1つは削除可能。
もう1つは、LUNを1つ削除するだけでターゲットは消さない形になる。
この辺りは、各自がどのように iSCSI ボリュームを作っていたかに依存するので、チェックするように。
まずは、自動ログインの解除からだ。
(gemini) $ iscsiadm --mode session
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
両ターゲット名と、それぞれへの自動ログインが automatic になっていることを確認しておく。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--logout
(gemini) $ iscsiadm --mode session
ログアウトしたことを確認する。
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
この時点では自動ログインはまだ automatic のままだ。
自動ログインを解除する。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op update \
--name node.startup \
--value manual
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
使用しない方のターゲットが manual に変化したことを確認する。

続いて、使用しない方のターゲットのエントリを削除する。
前回は削除する方法が分からず discovery を実行したが、削除する方法が分かったのでその方法を実施。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op delete
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
エントリが一つ消えて、残っている方のログインは automatic のままだ。

ココまで出来たら、iSCSI ストレージ側で不要な LUN、ターゲットを削除しよう。

最後に、念のために設定の再読み込み。(多分不要)
(gemini) $ sudo systemctl daemon-reload

これで gemini は完了。
必要に応じて、再起動して確認しよう。

使わなくなった iSCSI ボリュームの整理(aquarius)

そういえば、過去に作って現在使用していない iSCSI ボリュームが、aquarius / sagittarius ともに残っていた。
もう使わないので整理してしまおう。

まずは aqaurius から。
(aquarius) $ lsblk
これを見てみると、 /dev/sdb → /dev/mapper/mpatha → /dev/vg-kvm が未使用になっている。
＃何度か再起動しているウチに、自動的に multipath 制御下になったようだ。

まずは、/etc/lvm/lvm.conf に当該ボリューム(vg)が定義されていないか確認。
(aquarius) $ grep vg-kvm /etc/lvm/lvm.conf
もし定義されていたら、削除しておこう。

続いて、lvm 構成情報の削除。
(aquarius) $ sudo vgchange -a n vg-kvm
(aquarius) $ sudo lvremove vg-kvm/lv-etc-libvirt
(aquarius) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(aquarius) $ sudo vgremove vg-kvm
(aquarius) $ lsblk

続いて、multipath から削除
(aquarius) $ sudo multipath -ll
(aquarius) $ sudo multipath -f /dev/mapper/mpatha
(aquarius) $ sudo multipath -ll

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

wwids ファイルはコメント化、bindings ファイルにはエントリが残っている状態なので、この際削除してしまおう。
(aquarius) $ sudo vi /etc/multipath/bindings
(mpatha の行を削除)
(aquarius) $ sudo vi /etc/multipath/wwids
(コメント化された行を削除)

続いて、OS から当該デバイスの削除だ。
(aqaurius) $ lsblk
(aquarius) $ sudo bash -c "echo 1 > /sys/block/sdb/device/delete"
(aquarius) $ lsblk

この領域は iSCSI で、当該ターゲットはこの1つしか LUN が無い。
そのため、この iSCSI ターゲットにはログインする必要も無く、ログイン用の設定も不要だ。
その辺りの整理を行う。
(aquarius) $ iscsiadm --mode session
(iSCSI ターゲットの名前を確認)
(aquarius) $ sudo iscsiadm --mode node \
--targetname (先程確認したターゲット名) \
--logout
(aquarius) $ iscsiadm --mode session
(ログアウトしたことを確認する)
(aquarius) $ sudo iscsiadm --mode node \
--targetname (先程確認したターゲット名) \
--op update \
--name node.startup \
--value manual
(aquarius) $ sudo iscsiadm --mode node \
--op show \
--targetname (先程確認したターゲット名)
(node.startup が manual になったことを確認)

これで、iSCSI ターゲットへの自動ログインは無くなったはずだ。
ここまで来たら、次はストレージ側で当該 LUN と iSCSI ターゲットを削除しよう。

ストレージ側で削除が完了しても、 aquarius 側は当該 iSCSI ターゲットの情報は残っている。
どうやって削除するのか良くわからないので、iSCSI ターゲットを再スキャンしてしまおう。
(aquarius) $ sudo iscsiadm --mode discovery \
--type sendtargets \
--portal (NASのIPアドレス)
(aquarius) $ sudo ls -F /etc/iscsi/nodes/

使わなくなった iSCSI ターゲットのエントリが消えたはずだ。
が、何故かここまでの手順を踏むと、もう1つの iSCSI ターゲット(kvmcluster)への自動ログインも解除されてしまう。
合わせて自動ログイン設定しておこう。
(aquarius) $ sudo iscsiadm --mode node \
--targetname (有効にしたい方のターゲット名) \
--op update \
--name node.startup \
--value automatic

念のために、設定情報をリロードしておく。(多分不要)
(aquarius) $ sudo systemctl daemon-reload

これで完了だ。必要なら再起動もしておこう。
次回、同じように sagittarius に実施する。

/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 の導入だ。

OpenvSwitch と open-iscsi の起動停止順

今度は、主題の通りの件だ。
gemini / cancer のペアの時に、ココで実施した内容の前半部分になる。
こちらも、sagittarius / aquarius で同時に実施する。
＃例によって、仮想マシンは停止しておいてくれ。

$ cd /lib/systemd/system
$ sudo cp -pi open-iscsi.service open-iscsi.service.orig
$ 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
--ココまで

$ sudo systemctl daemon-reload

この状態で再起動して、刺さる現象が消えたかどうか…。
$ df
(iscsi領域がマウントされていること)
$ sudo systemctl reboot

とりあえずOK。
次は multipathd の導入かな？

これまでを踏まえて、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 化

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

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

とりあえず、対策を gemini にも

前回までで、(全てではないにしても)問題がある程度解消出来た。
cancer に対して実施していたので、gemini にも同様の対処を施すことにする。

(gemini) $ cd /lib/systemd/system
(gemini) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(gemini) $ 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
--ココまで
(gemini) $ cd

(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo vgchange -asy vg-gfs2
(gemini) $ sudo systemctl start /mnt/gfs2

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

(gemini) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6
↓
ExecStart=/bin/sleep 10
--ココまで
(gemini) $ sudo systemctl daemon-reload

再起動して確認
(gemini) $ sudo systemctl reboot

おしまい。

シャットダウン時に刺さる現象(その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ボリュームのLVMが有効化されるまで(その3：多分完結)

--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--

悩んで悩んで悩んで、どうやら見当違いのところを調査していたらしい…。

まず、ネットワーク設定のディレクトリに、geminiを作成した時の設定情報が残っていた。
そのファイルがまず不要だったので削除する。
(gemini/cancerを作る時の基本的な手順は省略してしまっているが、ココのタイミングで作ったと思われるファイルだ…。)
(gemini) $ cd /etc/network/interfaces.d
(gemini) $ ls -l ens3
(gemini) $ sudo cat ens3
(gemini) $ sudo rm ens3
(gemini) $ ls -l

それから、ココやココではOpenvSwitchのブリッジにIPアドレスを付与しているように見えるが、どうやらこれは正しく無いようだ。
実際にはやはり、NICやNICから作るbondingに対して、IPを付与するようだ。
(確かに、違和感はあった。)

というわけで、ブリッジのIP定義ファイルとNICのIP定義ファイルを書き換える。
まずは、NICのIP定義ファイル。
(gemini) $ sudo vi 0110.ens3
--以下のように行を追加＆修正
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type   OVSPort
↓(下線行を追加＆修正)
auto ens3
allow-br-external ens3
iface ens3 inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_bridge br-external
ovs_type OVSPort

dns-nameservers 192.168.55.1
--ココまで

続いて、ブリッジのIP定義ファイル
(gemini) $ sudo vi 0010.br-external
--以下のように修正＆行削除
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3

dns-nameservers 192.168.55.1
↓
auto br-external
allow-ovs br-external
iface br-external inet manual
ovs_type OVSBridge
ovs_ports ens3
--ココまで

更に、ココの最後に無効化したnetworking.serviceはやはり必要なようなので、有効化しておく。
(gemini) $ systemctl is-enabled networking.service
(gemini) $ sudo systemctl enable networking.service
(少し時間かかってエラーになるかもしれないけど我慢だ)
(gemini) $ systemctl is-enabled networking.service

そうしたら再起動してみる。
(gemini) $ sudo shutdown -r now

起動してきたら確認。
(gemini) $ systemctl status
Failedが無くなった！

(gemini) $ sudo vgs
ちゃんと表示される…。

(gemini) $ sudo iscsiadm -m session
ログインできてる。

そうか…OpenvSwitchの設定をミスってただけなのか…。
やっと、長いこと悩んでいた原因が分かって修正方法も分かった…。

次回は、これにそってaquariusの修正を行う。

--2017/03/24追記
根本的に間違えていた。今はまだ調査を続行しているけど、↑の設定は根本的に誤り。
まだ対応方法は不明だけど、↑のやり方は間違いなので、元に戻しておいた方がいい。

iSCSIボリュームのLVMが有効化されるまで(その2)

--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--

未だ解決出来ていないのだが、前回からの再起動後、systemdの状態をよく見てみたら、corosync.serviceの起動にも失敗している。
はて？cancerの方はどうだ？
(cancer) $ sudo shutdown -r now
(cancer) $ systemctl status corosync.service
問題なく起動している。
なんとまぁ…geminiに対する変更処理で、corosyncにまで影響が出てしまった。
これは要調査だな…。

ってどうやら、dlm.serviceも正常起動しなくなってるぞ。
これは大ダメージだ。

とりあえず状態の整理。

• /etc/libvirt等のKVM用ファイルシステムは未マウント
• NAS領域も未マウント
• vg確認・操作系オペレーションはハング(vgs)
• iSCSIターゲットへのログインは成功(iscsadm -m session)
• ブロックデバイスは認識済み(lsblk)
• corosync.serviceはfailed
• dlm.serviceはinactive
• clvm.serviceはinactive(これはcancerも)
• multipathは認識済み

となると、corosync.serviceから確認してみるか。

(gemini) $ cat /lib/systemd/system/corosync.service
要件として、network-online.targetが入っている。
ステータスは…
(gemini) $ systemctl status network-online.target
activeだ。
条件は…
(gemini) $ cat /lib/systemd/system/network-online.target
前提条件としてnetwork.targetが入っている。
ステータスは当然…
(gemini) $ systemctl status network.target
activeだ。

う～ん。corosync.serviceが起動していないのは何故だろう？
試しに起動してみる。
(gemini) $ sudo systemctl start corosync.service
(gemini) $ systemctl status corosync.service
む？activeになったぞ…？

もう一度再起動して、再現確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status corosync.service

あれ？今度は

• iSCSIターゲットへのログインは、片方失敗(gemini単独用ターゲットへのログイン失敗)
• corosync.serviceは起動状態
• dlm.serviceも起動状態
• clvmはinactive

になった。(その他の状態は一緒。)

………色々調べてたら、どうやらOpenvSwitchの設定がおかしいようだ………
ヘルプに書かれている設定方法じゃダメっぽい………

整理して書き直す…。