各種リソース作成

さて、いよいよ大詰めだ。

各種リソースの作成、リソースの制約の付与、そして動作確認だ。
今回必要なのは、

• dlm
• clvmd
• gfs2マウント

の3つのはず。
で、依存関係としては…
dlm起動→clvmd起動→gfs2マウント
となる様子。
＃あれ？ってことはgfs2を使用しないクラスターLVMでも、dlmは必要なのか？
＃nfsクラスター構築時に検証してみよう。

まずはdlmリソースの作成
$ sudo pcs resource show
(sagittarius) $ sudo pcs resource create dlm \
  ocf:pacemaker:controld \
  op monitor \
       interval=30s \
       on-fail=fence \
     clone \
     interleave=true \
     ordered=true
$ sudo pcs resource show
リソースが出来たし、いきなり起動した。
詳細確認
$ sudo pcs resource show dlm-clone

sagittarius/aquarius どちらも ps コマンドで確認したら、dlm プロセスが動き出しているはずだ。

続いて、clvmdリソースの作成。
(sagittarius) $ sudo pcs resource create clvmd ocf:heartbeat:clvm \
  op monitor interval=30s on-fail=fence \
  clone \
  interleave=true \
  ordered=true
$ sudo pcs status
数秒後、sagittarius/aquarius 両ノードで clvmd-clone リソースが起動してくるはずだ。
$ ps -ef | grep clvmd | grep -v grep
プロセスも起動してくる。

clvmd-clone リソースを停止すれば、clvmdプロセスも落ちるはず。
$ sudo pcs resource disable clvmd-clone
$ sudo pcs status
$ ps -ef | grep clvmd | grep -v grep
$ sudo pcs resource enable clvmd-clone
$ sudo pcs status
$ ps -ef | grep clvmd | grep -v grep

clvmd-clone リソースの追加ができたので、dlm リソースとの順序と起動ノードの設定。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start dlm-clone then clvmd-clone
$ sudo pcs constraint colocation add clvmd-clone with dlm-clone
$ sudo pcs constraint show --full

そういえば、clvmd リソースが起動したら、過去に作ってあった共有ボリューム(kvmcluster VG)もアクティベートされたぞ。

そしたら、ファイルシステムマウントのリソース作成。
(sagittarius) $ sudo pcs resource create shared-pool Filesystem \
    device="/dev/kvmcluster/var-lib-libvirt" \
    directory="/var/lib/libvirt" \
    fstype="gfs2" \
    op monitor interval=10s on-fail=fence clone interleave=true
$ sudo pcs status
動き出した！
$ sudo pcs resource show shared-pool
$ df /var/lib/libvirt
両ノードでちゃんとマウントされた！

clvmdの時と同じように、順序と起動ノードの設定をしておこう。
$ sudo pcs constraint show --full
$ sudo pcs constraint order start clvmd-clone then shared-pool-clone
$ sudo pcs constraint colocation add shared-pool-clone with clvmd-clone
$ sudo pcs constraint show --full

できた！

しかし、別の問題が発生。

次回はその問題の確認と対策だ…。結構メンドウだよ…。

2019/06/20 追記
ファイルシステムマウントのリソース、クローンリソース化するのなら、force_clones というパラメータを yes に設定しておく必要があるようだ。
実際のところ、違いがわからなかったんだけど、マニュアル上はそう書いてあるよう。
というわけで、設定を変更しておく。

$ sudo pcs resource update shared-pool force_clones=yes
$ sudo pcs resource show shared-pool

設定が反映されていれば OK だ。

あれ？libvirt-binとか、pacemakerのリソースにしないとアカン？

gfs2をpacemakerで使用するための前提を色々調査していたけど…。

gfs2を複数ノードで使用するためには、clvmdとdlmが必要。

gfs2はKVMの仮想ディスク領域で使用。

ということは、KVMの構成要素であるlibvirt-binとかもpacemakerのクラスタリソースに入れて、gfs2より後に起動しないとアカンのかな？

いや、でも仮想マシンが起動していない限り、特に仮想ディスク領域を使用している様子は無いな…。

pacemakerのリソースには入れずに実行してみて、ダメだったらリソースに入れるか。

あかん。まだや。

https://uramocha02.blogspot.com/2019/05/2.html
ココで、片方のノードがダウンした時の、もう片方のノードの運用について記載したけど、まだ問題があった。

上記は、片方のノードを正常停止(systemctl poweroff)してから、もう片方のノードを運用する、というスタンスで書いていた。
ところが、正常停止ではなく異常終了(電源停止などによるクラッシュ)の時は、生き残っている方のノードもマトモに稼働しない、ということが判明。
この時、生き残っている方のクラスタリソース、dlmが落ちるという事象が発生している。
これ、dlmのパラメータ(/etc/dlm/dlm.conf)を適切に設定すれば良いんだと思っていたんだが、どうも良くワカラン。そもそも、dlmに関するドキュメント類が薄すぎるんだよなー。

もっと調べないとアカンかなぁ。まぁdlmは、GFS2等の共有ファイルシステムを使っている時にのみ利用するデーモンだから、情報量少ないのはしょうがないか…。

イマイチ本運用まで到達出来ないなぁ。

クラスタ用LVMとファイルシステム作成(gfs2用)

フェンシングが全然わからず、すげー時間がかかった…。

というわけで、今度はgemini/cancerで共有しているディスクに、LVM構成とgfs2ファイルシステムを作成する。

この辺の内容で既に検証してるけど、今一度整理しよう。

当時の手順、間違いもあるから。

あと、サービスの導入やら起動やらを変更しているので、gemini/cancerとも再起動しておいた方が良いかな。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ systemctl status lvm2-cluster-activation.service
(cancer) $ systemctl status lvm2-cluster-activation.service

起動出来てなかった。
(gemini) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
              /etc/systemd/system/lvm2-cluster-activation.service
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
              /etc/systemd/system/lvm2-cluster-activation.service
(gemini) $ sudo vi /etc/systemd/system/lvm2-cluster-activation.service
--以下のように修正
After=lvm2-clvmd.service lvm2-cmirrord.service
↓
#After=lvm2-clvmd.service lvm2-cmirrord.service
After=lvm2-clvmd.service
--ココまで
cancerも同様に修正しておく。

修正終わったら反映。
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl daemon-reload
(gemini) $ systemctl status lvm2-cluster-activation.service
(cancer) $ systemctl status lvm2-cluster-activation.service

これで起動してみる。
(gemini) $ sudo systemctl start lvm2-cluster-activation.service
やっぱり起動しない…。

まずは、VGの作成。

同じ仮想ディスクをgemini/cancerの両方に接続しており、いずれも/dev/vdbとして見えている。

(gemini) $ lsblk

(cancer) $ lsblk

これを使って作成していく。

(gemini) $ sudo pvcreate /dev/vdb

(gemini) $ sudo vgcreate vg-gfs2 /dev/vdb

(gemini) $ sudo vgdisplay vg-gfs2

(gemini) $ sudo lvcreate -L 10G -n lv-gfs2 vg-gfs2

(gemini) $ sudo vgdisplay -v vg-gfs2

(cancer) $ sudo vgdisplay -v vg-gfs2

なぜか、意図的にクラスタマークを付与(vgchange -c y)しなくても、クラスタマークが付与された。

さて、LVまで作成できたので、今度はファイルシステムだ。
(gemini) $ sudo mkfs.gfs2 -j2 -p lock_dlm -t gfs2-cluster:fs-gfs2 /dev/vg-gfs2/lv-gfs2
-tオプションは、「クラスタ名」＋「:」＋「任意の名前」だ。
-jオプションはジャーナル数で、同時にマウントするノード数以上の数字を指定する必要がある。
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs2
(cancer) $ sudo tunegfs2 -l /dev/vg-gfs2/lv-gfs2

マウントできるのかな…？
(gemini) $ sudo mkdir /mnt/test
(gemini) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(gemini) $ df /mnt/test
(cancer) $ sudo mkdir /mnt/test
(cancer) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(cancer) $ df /mnt/test
マウントは出来た…。

読み書きテスト
(gemini) $ sudo bash -c "echo \"This is a test\" > /mnt/test/hoge"
(cancer) $ cat /mnt/test/hoge
出来た…。
lvm2-cluster-activation.service は必要無いのか？

一旦再起動して、再度マウントしてみるか…。
(gemini) $ sudo umount /mnt/test
(cancer) $ sudo umount /mnt/test
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(cancer) $ sudo mount /dev/vg-gfs2/lv-gfs2 /mnt/test
(gemini) $ cat /mnt/test/hoge
(cancer) $ cat /mnt/test/hoge
(gemini) $ sudo umount /mnt/test
(cancer) $ sudo umount /mnt/test

確認ができたら、リソースを作成する。
(gemini) $ sudo pcs resource create cluster-gfs Filesystem \
    device="/dev/vg-gfs2/lv-gfs2" \
    directory="/mnt/test" \
    fstype="gfs2" \
    op monitor interval=10s on-fail=fence clone interleave=true
(gemini) $ sudo pcs resource show cluster-gfs
(cancer) $ sudo pcs resource show cluster-gfs
できてる。

(gemini) $ df
(cancer) $ df
両方ともマウントされている。

これでいいのか…？
おっと、リソースの起動順と、起動するノードを定義してなかった。
clvmdより後に起動させる必要があるため、それに従って設定する。
(gemini) $ sudo pcs constraint order start clvmd-clone then cluster-gfs-clone
(gemini) $ sudo pcs constraint colocation add cluster-gfs-clone with clvmd-clone

(gemini) $ sudo pcs constraint show cluster-gfs-clone
(cancer) $ sudo pcs constraint show cluster-gfs-clone

これでいいのだろうか？
一旦再起動仕掛けてみる。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
片方ずつ落としたらどうなる？
(gemini) $ sudo systemctl poweroff
(cancer) $ cat /mnt/test/hoge

どうやら上手く行っているようだ。
ちょっと時間がかかって、全体の流れがわかりにくくなったので、次回はgemini/cancerを作り直して、もう一度ゼロから実施してみることとする。

クラスタ設定変更(gfs2用)

クラスタのベース部分が出来上がったところで、早速gfs2関連に手を出したいところだけど、その前に1つ、クラスタの設定を変更しておく必要がある。

redhatのサイトだけど、
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/global_file_system_2/ch-clustsetup-gfs2
が分かりやすいかな？
あと、ちょっと古いslideshare情報だけど、
https://www.slideshare.net/takmatsuo/osc2010-tokyo-fall-pacemaker
ここも見ておく必要がある。

今回の構成は

• 2ノードクラスタ
• 使用リソースはgfs2で、これを両ノードでマウントして使用

なので、クラスタのno-quorum-policyをfreezeに設定しておく必要がある。
この先、Ubuntu18.04(aries/pisces)のクラスタでは、nfs4のサービスを作る予定だが、そちらの場合はno-quorum-policyはignoreに設定しておく必要がありそうだ。

先程のredhatのサイトでは、コマンドで設定するように記載されているけど、今回作成中の環境では、手抜きでvirgoのpcsdから設定する。

ブラウザからvirgoのpcsdにログイン後、Managed Clustersからgfs2-clusterを選択して、gfs2-clusterの設定画面に移動しよう。
移動後、画面上部にあるタブからCLUSTER PROPERTIESを選択すると、クラスタ全体に関わる設定値を確認・変更できる。
クラスタ設定項目に、No Quorum Policyという設定項目があるはずだ。
プルダウンからfreezeを選択し、画面下部のApply Changesボタンを押して反映させよう。

これで、no-quorum-policyの変更ができた。

一応確認してみよう。
＃コマンドでの確認は、virgoから実行する方法が分からない。
＃gemini/cancerで実行してみよう。
(gemini) $ sudo pcs property show no-quorum-policy
freezeになっているのが確認できると思う。

とりあえず設定変更はココまで。

GFS2/DLM導入(16.04)

gemini/cancerクラスタは、gfs2ファイルシステムの運用を想定している。
そのため、gemini/cancer両ノードにgfs2ファイルシステムを導入しておく必要があった。
また、gfs2ファイルシステムを複数のノードで共有するためには、dlmも必要になる。
一緒に導入しておこう。
(gemini) $ sudo apt-get install gfs2-utils dlm
(cancer) $ sudo apt-get install gfs2-utils dlm

さくっと導入できた。

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

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

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

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

pacemaker検証(ノード名)

とりあえず、以下のノードを新規作成/再作成してpacemaker検証用にしよう。

• pisces/aries
  NFSv4クラスタ(Ubuntu18.04)
• gemini/cancer
  gfs2クラスタ(Ubuntu16.04)
• leo
  pcsd(Ubuntu18.04)
• virgo
  pcsd(Ubuntu16.04)

インストール構成は基本的にデフォルトで。細かい設定情報は、別途記載する。

pacemaker再検証(事前情報)

どうやら、gfs2を使用するには、pacemakerと組み合わせるのが基本のようだった。
今現在、KVMホストになっているaquariusとsagittariusは、pacemakerを使用せずにgfs2でファイルシステムを共有している。
これでは不安定になるようなので、本格的にpacemakerの検証をしたい。

で、少し調べてみたら、pcsdというのを使うと、ブラウザから制御できるようだ。
いくつか検証中の仮想マシンを潰して、以下の環境を検証してみたい。

• gfs2クラスタ検証(Ubuntu16.04)*2台
• NFSv4クラスタ検証(Ubuntu18.04)*2台
• pcsd検証(Ubuntu16.04)*1台
• pcsd検証(Ubuntu18.04)*1台

gfs2クラスタ検証は、検証内容をaquarius/sagittariusにフィードバックするため。
NFSv4は、自宅とは別の環境で検証している環境用で、複数のLinuxノードのホームディレクトリ(/home)共有を目的としている。
できればOpenLDAPによるアカウント統合も検証したい。
pcsd検証が2環境あるのは、単に16.04と18.04でそれぞれ確認してみたいというだけの理由だ。
別途確認してみたら、一度pcsdの管理下に置いたクラスタは、pcsd管理から外してもすぐに管理下に起き直すことができるようだ。
そのため、pcsd自体をHAクラスタにしなくても、同じクラスタを複数のpcsd管理下に置けるのではないか？と考えている。
そのため、2種類のHAクラスタを、両方のpcsd管理下に置くことを想定している。

もちろん、gfs2クラスタやNFSv4クラスタの各ノードでpcsd自体を稼働させる、ということも可能なはずだが、それは余裕があったら実装したい。

まぁゆっくりと…。

1804でGFS2(失敗)

1804のリリース前バージョンのバージョンアップ方法が分かったところで、sagittarius をバージョンアップしてみた。
結論、バージョンアップに失敗。
バージョンアップ自体は問題なく出来たが、共有ファイルシステムのgfs2がマウント出来ないという問題に当たった。
仮想マシンを配置する場所を全てgfs2にしているため、マウント出来ないのは致命的だ。
また、共有せずにローカルでgfs2を作成してもマウント出来なかった。
原因が判明しなかったため、事前に取得しておいた1604のバックアップでリストアし、元の環境に戻してある。
gfs2かLVMの問題だと考えられるため、仮想マシン上でgfs2を作成、マウント確認することで原因調査することにする。
調べてる時間あるかなぁ…。

corosync が落ちる？

とりあえず、gfs2 を復旧させて、2台のPC(aquarius / sagittairus)を起動しておいたんだけど、aquarius の corosync がクラッシュしてた…。

まだ corosync / dlm が不安定だな…。何が原因だろう…。

pegasus と cancerの仮想ディスクが…

dlm のクラッシュで、無理やりホストマシンを再起動繰り返してたら、/var/lib/libvirt の gfs2 領域がおかしくなったみたい。

で、アンマウントして fsck.gfs2 を実行。
かなり壊れていて、やっと復旧できたと思ったら、pegasus と cancer の仮想ディスクが消えてしまった…。
pegasus はバックアップがあったので、これから復旧してみるけど、cancer はバックアップ取ってない。
ま、cancer は実験環境だし、gemini とセットで作り直すツモリだからいいんだけどね。

みんなもゲストOS のバックアップ忘れないように…。

sagittarius の整理

これでようやく sagittarius の仮想マシンがゼロになった。
sagittarius の整理をしよう。

とは言っても、大きく「ログファイルの移動」と「専用ディスクの排除」「共有ボリュームのマウント」の3点だろう。

ログファイルの移動は、既にココの後半部で aquarius にて実施済み。
その手順をなぞればいい。

専用ディスクの排除は、今まで kvm 仮想マシンが載っていたディスク領域を排除することだが、まずはアンマウント状態にしておいて、後日削除、でいいだろう。
共有ボリュームのマウントと合わせて、やはりココの後半部で実施済みだ。

そのため、ざっとコマンドだけ並べておくことにする。

まずはログファイルの移動
(sagittarius) $ cd /var/log
(sagittarius) $ sudo tar cvf libvirt.tar libvirt
(sagittarius) $ sudo systemctl stop /var/log/libvirt
(sagittarius) $ sudo chmod 755 /var/log/libvirt
(sagittarius) $ sudo chown root:root /var/log/libvirt
(sagittarius) $ sudo tar xvf libvirt.tar
(sagittarius) $ sudo rmdir libvirt/lost+found
(sagittarius) $ ls libvirt
(sagittarius) $ sudo rm libvirt.tar
(sagittarius) $ cd

続いて、専用ディスクの取り外しと共有ディスクのマウント(/etc/fstab も書き換え)
(sagittarius) $ sudo systemctl stop /etc/libvirt
(sagittarius) $ sudo systemctl stop /var/lib/libvirt
(sagittarius) $ 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
--ココまで

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

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

多分この状態では、まだ共有仮想マシンが認識できていないと思う。
libvirt-bin を再起動することで認識させることが可能だ。
(sagittarius) $ virsh list --all
(sagittarius) $ sudo systemctl restart libvirt-bin.service
(sagittarius) $ virsh list --all

必要に応じて、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 )が足りない。
その為、次回はまず、仮想ディスク領域を拡張する手順を作る。
＃コレ以降、仮想ディスク領域の拡張は、特に書かないツモリ…。

ボリューム共有化の前に整理

最後に、sagittarius / aquarius 間で、仮想マシン領域を共有、という流れだけど、その前に今の構成を整理しておきたい。

今は、

• 物理マシンとして sagittarius / aquairus が稼働
• それぞれの上に複数の仮想マシンが稼働
• sagittarius 上の gemini / cancer はボリューム共有をしており、その上に更に仮想マシン(leo)が稼働

という状態。
分かりにくいので絵を描いてみる。

乱立した仮想マシン

うむ。更に分かりにくいか…。

非常に混乱しそうな状況なのだが、これをマイグレーション機能等を行使しながら共有ボリューム化していきたいと思っている。

まずは leo を sagittarius へ。
仮想マシン on 仮想マシン の状態になっている leo を、sagittarius 上へ移動させたいと思う。

leoをsagittariusへ

gemini / cancer と sagittarius はボリューム共有をしていないため、これまで試してきたライブマイグレーションは実施出来ないはずだ。
そのため、ディスク移動を含めたマイグレーション(leo稼動状態)を実施してみたい。
それがダメなら、leoを停止させた状態のオフラインマイグレーション、それでもダメなら、仮想マシン定義と仮想ディスクを手作業で移動、という方法。
ここで「ボリューム共有していないサーバ間での仮想マシンの移動」を身に着けておき、下の作業に応用する。

その後、aquarius 上に存在している仮想マシンを、全て sagittarius 上へ移動。

aquariusからsagittariusへ

aquarius / sagittiarius 共有のボリュームを作成し、aquarius の単体ボリュームに残ったファイルをコピー、単体ボリュームを削除。
＃この時点では、 aquarius ではマウントするが、sagittairus ではマウントさせない

共有ボリュームを作成

sagittarius 上に存在している仮想マシンを、全て aquarius 上に移動させる。
この作業で、仮想マシンの環境(仮想マシン定義、仮想マシンディスク)が全て共有ボリューム上に移動するはずだ。

sagittairusからaquariusへ

この時、構成上マイグレーション不可能な仮想マシンが最低3つ存在している。
gemini / cancer / pegasus だ。
gemini / cancer は、CPU定義を「ホストCPUの設定をコピーする」にしていて、CPUのジェネレーションが違う sagittarius から aquarius へはオンラインでは移動出来ないはず。(sagittarius:第6世代Core i7、aquarius:第5世代Core i7)
これらは、仮想マシンを停止した状態でのマイグレーション(オフラインマイグレーション)は可能なはずで、移動後に aquarius で起動することも出来ると想定している。
pegasus はその設定上、物理マシン(sagittarius)の持つデバイスを、一部直接マッピングしている。aquarius はそのデバイスを持っていないので、移動出来ないはずだ。
オフラインでなら移動出来ると思うが、移動先(aquarius)では起動出来ないはずなので、予め sagittarius 上で当該デバイスを外しておくことにする。

sagittairus の単体ボリュームを切り離し、共有ボリュームをマウント。
幾つかの仮想マシンの動作テストを行う。

sagittairusの単体ボリュームを削除

とまぁこんな感じで考えてみた。
実際に出来るかは分からないが、次回以降、この方向で進めていこうと思う。

corosync / dlm / gfs2

というわけで、corosync / dlm / gfs2 か。
この辺からの作業だ。
結構苦労した記憶があるので、今回も手こずるんだろうな…。
記憶を呼び戻しながら、整理しながら記載していくことにする。

まずは corosync の導入。
$ sudo apt-get update
$ sudo apt-get install corosync

$ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
$ sudo vi /etc/corosync/corosync.conf

一部修正
--ココから
totem {
cluster_name: debian
↓
cluster_name: kvmcluster

interface {
bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0
}
}
quorum {
    (2行追加)
two_node: 1
wait_for_all: 0
}
--ココまで
今回は、クラスタ名を「kvmclulster」にした。かっこ悪いか？

corosync の起動順変更
$ cd /lib/systemd/system
$ sudo cp -pi corosync.service corosync.service.orig

$ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで

$ sudo systemctl daemon-reload
$ sudo systemctl restart corosync.service
$ systemctl --no-pager -l status corosync.service

$ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig
$ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓
ExecStart=/bin/sleep 10
--ココまで
$ sudo systemctl daemon-reload
$ cd

dlm の導入だ。
$ sudo apt-get update
$ sudo apt-get install dlm

$ systemctl -l status dlm.service

$ sudo mkdir /etc/dlm
$ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
$ cat /etc/dlm/dlm.conf
--以下の内容になっていた
daemon_debug=0
foreground=1
log_debug=0
timewarn=0
protocol=detect
debug_logfile=0
enable_fscontrol=0
enable_plock=1
plock_debug=0
plock_rate_limit=0
plock_ownership=0
drop_resources_time=10000
drop_resources_count=10
drop_resources_age=10000
post_join_delay=30
enable_fencing=1
enable_concurrent_fencing=0
enable_startup_fencing=1
enable_quorum_fencing=1
enable_quorum_lockspace=1
help=-1
version=-1
--ココまで

$ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_fencing=1
↓この行を以下のように書き換え
enable_fencing=0
--ココまで

$ sudo systemctl restart dlm
$ systemctl --no-pager -l status dlm

$ dlm_tool ls
$ dlm_tool status

gfs2 の導入
$ sudo apt-get update
$ sudo apt-get install gfs2-utils

とりあえずはこんなもんかね。
次は CLVM の導入か…。

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

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

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

dlmのフェンシング(その4:fence_all /bin/true)

続いて、enable_fencing は 1 だけど、fence_all を /bin/true にする形を検証する。
前回と同様、gemini / cancer の /etc/dlm/dlm.conf を書き換えるところから。

(gemini) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=0
↓1に書き戻す
enable_fencing=1

1行追加する。
fence_all /bin/true
--ココまで

cancer も同様に。
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=0
↓1に書き戻す
enable_fencing=1

1行追加する
fence_all /bin/true
--ココまで

どうも、dlm.service の再起動が上手く行かなったので、leo を停止し、gemini / cancer は再起動する。
(leo) $ sudo systemctl poweroff
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot

状態確認だ。
(gemini) $ dlm_tool status
(cancer) $ dlm_tool status
(gemini) $ dlm_tool ls
(cancer) $ dlm_tool ls

前回のテスト前半部分はすっ飛ばして、leo を起動してテストする。

既に gemini 上で leo が動いていると思うので、前回の後半部分、仮想マシンの起動からテストする。
(gemini) $ virsh list --all
(gemini) $ virsh start leo
(gemini) $ virsh list --all

leo にログインし、ping を打ち続ける。
(leo) $ ping 192.168.55.130

leo を cancer へ移動。(今回は sagittarius から実行する。対象ホストに注意。)
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

gemini を強制再起動
(sagittarius) $ virsh reset gemini
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

(gemini の再起動が確認できたら) leo を gemini に移動。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

問題無いな…。
というわけで、この設定をそのまま採用しよう。

と思ったけど、dlm_controld がダウンする現象が発生した。
多分、その他のフェンシング設定が関係している気がする…。
enable_fencing=0 の方では発生しないっぽい…。

ちょっと調べたけど分からなかったので、当面は「その3」で記載した方法で進めていくことにする。
将来的に pacemaker を使う時に、もう一度検討することになると思う。

dlmのフェンシング(その3:enable_fencing=0)

というわけで、dlm.conf の enable_fencing を 0 に書き換えて試してみよう。
gemini / cancer の両ノードを起動して、dlm.conf を書き換える。

(gemini) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=1
↓
enable_fencing=0
--ココまで

cancer も同様に。
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=1
↓
enable_fencing=0
--ココまで

dlm.conf は、dlm.service だけが参照していると思うので、dlm.service の設定を読み直す。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl restart dlm.service
(gemini) $ sudo systemctl status dlm.service

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl restart dlm.service
(cancer) $ sudo systemctl status dlm.service

(gemini) $ dlm_tool status
(cancer) $ dlm_tool status
(gemini) $ dlm_tool ls
(cancer) $ dlm_tool ls

きちんと動いてそうなら、ココと同様にテストしてみる。
ホスト側から cancer の強制停止。
(sagittarius) $ date ; virsh destroy cancer

プロセスの確認
(gemini) $ ps -ef | grep dlm_controld | grep -v grep
プロセスは死んでない。

dlm の状態確認
(gemini) $ dlm_tool status
(gemini) $ dlm_tool ls

共有ファイルシステムの確認
(gemini) $ grep -e /etc/libvirt -e /var/lib/libvirt /etc/mtab
rw モードでマウントされていることを確認。

(gemini) $ sudo bash -c "sync;sync;sync"
(gemini) $ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"

(gemini) $ ls -l /etc/libvirt
(gemini) $ ls -l /var/lib/libvirt
ちゃんと読める。

cancer を起動したら、自動的に組み込まれるか？
(sagittarius) $ virsh start cancer
(gemini) $ dlm_tool status
(gemini) $ dlm_tool ls
自動的に組み込まれた。

どうやら上手く行ってるようだ。
なら今度は、仮想マシンのオンラインマイグレーションを含めた挙動確認してみるか。

流れとしては、

1. gemini 上で leo を起動
2. leo を cancer 上へ移動
3. gemini を強制再起動
4. leo を gemini へ移動

かな？

というわけで、gemini 上で leo を起動。
(gemini) $ virsh list --all
(gemini) $ virsh start leo
(gemini) $ virsh list --all

leo にログインし、ping を打ち続ける。
(leo) $ ping 192.168.55.130

leo を cancer へ移動。(今回は sagittarius から実行する。対象ホストに注意。)
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

gemini を強制再起動
(sagittarius) $ virsh reset gemini
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

(gemini の再起動が確認できたら) leo を gemini に移動。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

全然問題無さそうだ。

enable_fencing=0 のパターンはコレで終了かな？
次回は、enable_fencing=1 and fence_all /bin/true を試してみよう。