各種リソース作成

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

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

• 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 だ。

2ノード構成でのdlm.confやらcorosync.confやら

や～っと分かった！
2ノードクラスタが全然期待通りに動かなかったんだけど、どうやらこれで決定稿だ。
長かった…。

2ノードで組む場合は、corosync.conf は

• auto_tie_breaker: 0 (もしくは未設定)
• last_man_standing: 0 (もしくは未設定)
• two_node: 1

にする必要があった。
auto_tie_breaker や last_man_standing をごにょごにょと 1 に設定したりしたもんだから、two_node が働いていなかったようだ。
で、dlm.conf は特にいじる必要なく、デフォルトのままで良かったようだ。

corosync.conf の wait_for_all は、2ノードの場合は自動で 1 に設定され、2ノードともpacemakerが起動しないと、サービス(リソース)は自動起動しない。
手作業でブロック解除すれば、片ノードだけでも起動する。
wait_for_all を 0 に設定すれば、片ノードだけでもリソースは起動する。
この辺は、クラスタに対してどこまで信頼性・可用性を求めるかによって変わってくるので、好きなように設定を。

あと、サービスは、pacemaker/corosync/pcsd の3つはOS起動時に自動起動(systemd管理下)にして、dlm/clvmd は pacemaker のリソースにする必要があるようだ。

これを元に、もう一度 gemini/cancer を見直そう…。

シングルノード状態でのgfs2

いろいろ試しているうちに、いくつかまだ設定がおかしいと思われるところが見つかった。
致命的なのは、

• 片方のノード(例えばcancer)が障害で起動できない
• 生き残っている方のノード(この場合gemini)を再起動させると、clvmリソースが正常に立ち上がって来ない→gfs2が利用できない

という状態だ。
しかも、この状態だとgeminiが再起動できない。(停止処理でハングしてしまう)

調べていったら、起動後にdlmは起動するが、clvmdがうまく起動できていないのだが、clvmdがdlmと通信を行い、dlmがエラーを返すことで、clvmdが起動に失敗する、という流れのよう。
dlmがシングルノードで稼働している(相方が死んでいるので、シングルで稼働させても問題はない)という状態をうまく認識できていないのが問題のよう。

やっぱりdlmがネックになるなー。

dlmとclvmdの依存関係(gfs2用)

dlmとclvmdリソースの起動順を定義しておく必要があるようだ。
＃と言っても、dlmもclvmdもOS起動時にsystemdから起動されるので、あまり意味が無い気がするんだけど…。
＃RHEL7だと、systemdから起動させず、各リソース定義から起動させるのだろうか…。

RedHat社のサイトだと、以下のコマンドとして記載されている。
pcs constraint order start dlm-clone then clvmd-clone
pcs constraint colocation add clvmd-clone with dlm-clone
起動順だけでなく、「clvmdもdlmも同じノードで起動するよ」という制約も付けていた。

まずは起動順から。
pcsd の画面から dlm-cloneリソース か clvmd-cloneリソース の Resource Ordering Preferences から設定するようだ。

dlm-clone リソースから設定する場合は、以下のように入力する。

• Resource : clvmd-clone
• Action : starts
• Before/After : after dlm-clone
• Action : starts
• Score : 無し

これは、「dlm-clone が起動した後に、clvmd-cloneを起動させる」という意味だ。

clvmd-clone リソースから設定する場合は、以下のように入力する。

• Resource : dlm-clone
• Action : starts
• Before/After : before
• Action : starts
• Score : 無し

これは「dlm-clone を先に起動させる」という意味。

リソースの起動順はこれでおしまい。

続いて起動ノードの制約。
こちらは pcsd の dlm-cloneリソース か clvmd-cloneリソース の Resource Colocataion Preferences という設定画面から設定可能。
設定内容は以下の通り。

• Resource : 相手側のリソース名。clvmd-clone リソースから定義しているのなら、dlm-clone
• Together/Apart : Together
• Score : 無し(未設定だと INFINITY で設定される)

どちらか片方で設定すれば、もう片方からも自動設定されるぞ。

設定出来たら設定内容を確認してみよう。
(gemini) $ sudo pcs constraint show --full

依存関係等はこれで終了かな？

clvmdをクラスタリソースに(gfs2用)

RedHat社の手順だと、ココで clvmd をクラスタリソースとして定義している。

んが、gemini と cancer には、まだ clvmd をインストールしていない。
なので、このタイミングでまずインストールする。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install clvm
(gemini) $ dpkg -l clvm
(gemiin) $ dpkg -L clvm

cancer でも。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install clvm
(cancer) $ dpkg -l clvm
(cancer) $ dpkg -L clvm

インストールが終わったら、clvmd をクラスタリソースとして定義する。
RedHat社のサイトでは、以下のコマンドを実行している。
pcs resource create clvmd ocf:heartbeat:clvm \
  op monitor interval=30s on-fail=fence \
  clone \
  interleave=true \
  ordered=true

dlmリソースを作成した時とよく似ている。
ということは、その時と同じように設定すればいいってことだ。
pcsdの画面を使って、RESOURCESタブからAddを選択。
以下のように入力する。

• Class/Provider : ocf:heartbeat
• Type : clvm
• Resource Group : None
• Clone : チェックOn
• Master/Slave : チェックOff
• Disabled : チェックOff
• ResourceID : clvmd
• with_cmirrord : なし
• configdir : なし
• daemon_options : なし
• active_vgs : なし

これで作成。

あれ？確かにclvmd-cloneとclvmdのリソースは作成されたけど、ステータスがblockedになってしまった。
clvmdが起動していないとダメなのか？

う～ん。強制的にリソースを起動してみると…。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
動いたけど…起動時に「lvmetadが無効になっているのに起動してるで。有効化して再起動しな。」って言われてる気がするが…。
lvmetad は無効化するのが正しいはずなので、lvmetad を停止すればいいのかな？
とりあえず、clvmdリソースは停止する。
(gemini) $ sudo pcs resource debug-stop clvmd
(gemini) $ ps -ef | grep clvmd

lvmetadの状態を確認してみよう。
(gemini) $ systemctl status lvm2-lvmetad.service
起動していて、かつ自動起動Offだ。(disabled)
止めてしまおう。
(gemini) $ sudo systemctl stop lvm2-lvmetad.service
(gemini) $ systemctl status lvm2-lvmetad.service
なんか、lvm2-lvmetad.socketが有効だぞ、と言われたけど、一旦無視する。

これでもう一回、強制起動を。
(gemini) $ sudo pcs resource debug-start clvmd
(gemini) $ ps -ef | grep clvmd
先程のワーニングは消えた。

とりあえず止める。
(gemini) $ sudo pcs resource debug-stop clvmd

となると、systemctl から clvmd が起動してくれればイケそうだな。
以前、clvmd の起動はココで苦労したんだけど、この記事若干間違っているので、ここで再度整理して実行しよう。

lvm2-clvmd.service の定義ファイルが誤っているっぽいので、コピーして修正する。
(gemini) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
    /etc/systemd/system/
(gemini) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS
↓
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----
以前の記事では、うだうだと色々いじっているが、実際にいじるのは上記だけだ。

これで起動してみる。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl start lvm2-cluster-activation.service

pcsd の画面から、 clvmd-clone リソースを Cleanup して暫く待ったら、無事に動き出した。(ただし、リソース自体はgeminiでしか動いていない。cancer側の修正が出来てないから当たり前だが)
(gemini) $ sudo pcs resource

lvm2-cluster-activation.service は自動起動になっていないようなので、自動起動にしておく。
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service
(gemini) $ sudo systemctl enable lvm2-cluster-activation.service
(gemini) $ systemctl is-enabled lvm2-cluster-activation.service

同じようにcancerをカスタマイズする。
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
    /etc/systemd/system/
(cancer) $ sudo vi /etc/systemd/system/lvm2-clvmd.service
----
ExecStart=/sbin/clvmd $CLVMD_OPTS
↓
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
----

起動してみる。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl start lvm2-cluster-activation.service

また、pcsd の画面から、clvm-clone リソースを Cleanup して暫く待つ。
cancer側でも動いているのを確認する。
(cancer) $ sudo pcs resource

動いているのが確認できたら、cancer でも lvm2-cluster-activation.service を自動起動にする。
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service
(cancer) $ sudo systemctl enable lvm2-cluster-activation.service
(cancer) $ systemctl is-enabled lvm2-cluster-activation.service

さて、あとは op monitor interval=30s on-fail=fence と interleave=true ordered=true の設定だな。
サクッと片付けよう。
(gemini) $ sudo pcs resource show clvmd-clone
(gemini) $ sudo pcs resource op remove clvmd monitor
(gemini) $ sudo pcs resource op add clvmd monitor interval=30s on-fail=fence
(gemini) $ sudo pcs resource show clvmd-clone

interleave=true と ordered=true は、pcsd の画面の Meta Attrib から足したらおしまいだ。

とりあえずココまで。

追記
cancerのlvmetadを止めておくのを忘れていたので止めておく。
(cancer) $ systemctl status lvm2-lvmetad.service
(cancer) $ sudo systemctl stop lvm2-lvmetad.service
(cancer) $ systemctl status lvm2-lvmetad.service

cancer で共有ボリュームをマウント

続いて共有ボリュームのマウントだ。

単純に /etc/fstab を書き換えて、OS再起動等でイケるんだけど…。
今回 cancer を再作成している過程で、ちょっと気になる点があった。

今まで、sagittarius / aquarius / gemini でgfs2共有ボリュームをマウントする時、「x-systemd.requires=dlm.service」という条件を付けていた。
gfs2 をマウントするだけならこれでいいんだけど、clvmd(lvm2-clvmd.service) によって管理され、lvm2-cluster-activation.service によってアクティベートされる領域は、前提条件が変わってくるのではないだろうか？

実際に、/lib/systemd/system/lvm2-clvmd.service には「After=dlm.service corosync.service」という条件が付いており、 /lib/systemd/system/lvm2-cluster-activation.service には「After=lvm2-clvmd.service」という条件が付いている。

つまり、dlm.service、lvm2-clvmd.service、lvm2-cluster-activation.serivce の3つのサービスの起動順は、

1. dlm.service
2. lvm2-clvmd.service
3. lvm2-cluster-activation.service

になっているはず。
そして、CLVM管理のボリュームは、最後の lvm2-cluster-activation.service によってアクティベーションされるということを考えると、このボリュームはこのサービスの起動後出ないとマウント出来ないはずだ。

つまり、/etc/fstab につける条件は、「x-systemd.requires=dlm.service」ではなく「x-systemd.requires=lvm2-cluster-activation.service」だと考えられる。

という前提を踏まえて、作業開始。
/etc/fstab 書き換え
(cancer) $ sudo vi /etc/fstab
--ココから
以下の行を追加
/dev/mapper/vg--gfs2-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=lvm2-cluster-activation.service 0 0
/dev/mapper/vg--gfs2-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=lvm2-cluster-activation.service 0 0
--ココまで

追記が終わったら反映させてみる。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl start /etc/libvirt
(cancer) $ sudo systemctl start /var/lib/libvirt
(cancer) $ df
(cancer) $ ls -ld /etc/libvirt
(cancer) $ ls -ld /var/lib/libvirt
マウント出来たようだ。

この状態なら、libvirt に OpenvSwitch が使えるようになっているはずだけど…
(cancer) $ virsh net-list --all
(cancer) $ virsh list --all
まだ libvirt に反映されていない。

というわけで、libvirt-bin を再読込み。
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh net-list --all
(cancer) $ virsh list --all
無事に認識された。

後は OS再起動できちんとマウントされるかどうか…。
(cancer) $ sudo systemctl reboot
(cancer) $ df
問題なくマウント出来ている。
(cancer) $ virsh list --all
(cancer) $ virsh net-list --all
libvirt の方も共有ディスク側の情報を得ているようだ。

…が…
何度か再起動確認をしていったら、停止時は問題出てないが、起動時に corosync/dlm が上手く起動しない現象がまた発生。(一回だけ)
イマイチ原因がつかめない。
う～ん…。その後何度か再起動しているが、発生したのは一回だけ…。う～ん…。

気を取り直して…。
sagittarius / aquarius / gemini の /etc/fstab も合わせて書き換えておこう。
$ sudo vi /etc/fstab
--
x-systemd.requires=dlm.service を x-systemd.requires=lvm2-cluster-activation.service に書き換え(2箇所？)
--
$ cat /run/systemd/generator/etc-libvirt.mount
$ cat /run/systemd/generator/var-lib-libvirt.mount
$ sudo systemctl daemon-reload
$ cat /run/systemd/generator/etc-libvirt.mount
$ cat /run/systemd/generator/var-lib-libvirt.mount

これでオシマイ。

cancer で CLVM

続いて、CLVM の設定だ。
こちらも、過去実績通り。

パッケージ類は導入済みなので、ガツガツ設定を施していく。
/etc/init.d/clvm の無効化
(cancer) $ systemctl --no-pager -l status clvm.service
(cancer) $ systemctl is-enabled clvm.service
(cancer) $ sudo systemctl disable clvm.service
(cancer) $ systemctl is-enabled clvm.service
(cancer) $ systemctl is-active clvm.service
(cancer) $ systemctl --no-pager -l status clvm.service

起動停止処理の変更
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-cluster-activation.service \
/lib/systemd/system/lvm2-cluster-activation.service.orig
(cancer) $ sudo cp -pi /lib/systemd/system/lvm2-clvmd.service \
/lib/systemd/system/lvm2-clvmd.service.orig

(cancer) $ sudo vi /lib/systemd/system/lvm2-cluster-activation.service
--ココから
After=lvm2-clvmd.service lvm2-cmirrord.service
↓(lvm2-cmirrord.service を削除)
After=lvm2-clvmd.service

EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
--ココまで

(cancer) $ sudo vi /lib/systemd/system/lvm2-clvmd.service
--ココから
EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd

ExecStart=/sbin/clvmd $CLVMD_OPTS
↓(パスを /usr/sbin/clvmd に変更)
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
--ココまで
(ちなみに、lvm2-cmirrord.service は Ubuntu 17.10 の開発中のパッケージには含まれているようだ。LTS版は 18.04 で導入が間に合うかな？)

設定の反映と起動
(cancer) $ sudo systemctl daemon-reload
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ sudo systemctl start lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ dlm_tool status

lvmconf の変更
(cancer) $ sudo lvmconf --enable-cluster --services --startstopservices
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service

OS 再起動して結果確認
(cancer) $ systemctl status
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl --no-pager -l status lvm2-clvmd.service
(cancer) $ systemctl --no-pager -l status lvm2-cluster-activation.service
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

良さそうだな。
次は multipathd 関連を。(共有ボリュームを使うのはその先で。)

シャットダウン時に刺さる現象再び！

シャットダウン・リブート時にハングする現象、ココで暫定対策を施しておいたんだけど、また再発した。
遠隔からリブート仕掛けたらハングしてしまったので、何が起きたのかは分からず。
帰宅後にコンソールを見てみてもよく分からなかった。

ただ、どうも dlm 絡みのような気がしてならない。
問題が起きたから dlm がトラブったのか、dlm がトラブったから問題が発生したのか、どちらが主要因かは分からない。

何せ、再現性に乏しいのが辛いところ。

とりあえず、lvm2-cluster-activation.service の停止処理の sleep 10 と、openvswitch-switch.service の起動処理の sleep 10 を、sleep 20 に伸ばしてみた。
直接の原因が分からないので、これが効果あるのかどうかも分からない。

取り急ぎ、これで逃げておくことにする。

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の単体ボリュームを削除

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

続いて CLVM

続いて、CLVM(Clustered LVM) か。

こちらも過去の作業をまとめて記載する。
例によって、プロンプトの前にホスト名が無い場合は、sagittarius / aquarius 両方で共通の作業だ。

まずはパッケージの導入

$ sudo apt-get update
$ sudo apt-get install clvm
$ dpkg -L clvm
$ systemctl --no-pager -l status lvm2-clvmd.service
$ systemctl --no-pager -l status lvm2-cluster-activation.service

lvmconf の変更(これはもしかしたら、起動停止処理の変更の後の方が良かったかも)

$ sudo sudo lvmconf --enable-cluster --services --startstopservices
$ systemctl --no-pager -l status lvm2-clvmd.service
$ systemctl --no-pager -l status lvm2-cluster-activation.service

起動停止処理の変更

$ cd /lib/systemd/system
$ sudo cp -pi lvm2-cluster-activation.service \
lvm2-cluster-activation.service.orig
$ sudo cp -pi lvm2-clvmd.service \
lvm2-clvmd.service.orig

$ sudo vi lvm2-cluster-activation.service
--ココから
After=lvm2-clvmd.service lvm2-cmirrord.service
↓(コメント化して、lvm2-cmirrord.serviceを削除した行を作成)
#After=lvm2-clvmd.service lvm2-cmirrord.service
After=lvm2-clvmd.service

EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd

[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで

$ sudo vi lvm2-clvmd.service
--ココから
EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd

ExecStart=/sbin/clvmd $CLVMD_OPTS
↓(この行はコメントにし、パスを/usr/sbin/clvmdにした行を作成
#ExecStart=/sbin/clvmd $CLVMD_OPTS
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
--ココまで

設定の反映と起動

$ sudo systemctl daemon-reload

$ systemctl --no-pager -l status lvm2-cluster-activation.service
$ systemctl --no-pager -l status lvm2-clvmd.service
$ sudo systemctl start lvm2-cluster-activation.service
$ systemctl --no-pager -l status lvm2-cluster-activation.service
$ systemctl --no-pager -l status lvm2-clvmd.service

/etc/init.d/clvm の無効化

$ systemctl --no-pager -l status clvm.service
$ systemctl is-enabled clvm.service
$ sudo systemctl disable clvm.service
$ systemctl is-enabled clvm.service
$ systemctl is-active clvm.service
$ systemctl --no-pager -l status clvm.service

$ cd

おしまい。

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

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

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

確認前にバックアップ

前回、/etc/libvirt を共有する構成を作った。

で、この上で幾つか検証をしようと思う。
実は既に検証しているんだが、そこで想定外の挙動を示した。
その結果、一部データがロストしてしまい、ちょっと復旧に手間がかかった。(致命傷を受ける前に対処出来たけど…)

というわけで、検証前に現状をバックアップしておこう。

LVMスナップショットを取れればいいんだけど、CLVMによって共有モードでアクティベートされた領域は、スナップショットが取れないらしい。
実際に試してみると、「(lvol名) must be active exclusively to create snapshot」というメッセージが出て、スナップショットが作られない。

これもまた想定外だな…いやまぁ、クラスタボリュームでスナップショットが作れないことはある程度予想できていたが…。

とりあえず、バックアップの方法については別途検討するとして、今回は仮想マシンを落として、丸っとバックアップを取ることにする。

(仮想マシン leo は停止しておくこと)
まずはバックアップ用のファイルシステムの作成
(gemini) $ sudo lvcreate -C n -n backup -L 20G vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo lvchange -a y vg-gfs2/backup
(gemini) $ sudo mkfs.ext4 /dev/vg-gfs2/backup

マウントしてバックアップ
(gemini) $ sudo mkdir /mnt/backup
(gemini) $ sudo mount /dev/vg-gfs2/backup /mnt/backup
(gemini) $ sudo chmod 777 /mnt/backup
(gemini) $ sudo -i
(gemini) # cd /etc
(gemini) # tar cvjSf /mnt/backup/etc-libvirt.tbz libvirt
(gemini) # tar tvjf /mnt/backup/etc-libvirt.tbz
(gemini) # cd /var/lib
(gemini) # tar cvjSf /mnt/backup/var-lib-libvirt.tbz libvirt
(gemini) # tar tvjf /mnt/backup/var-lib-libvirt.tbz
(gemini) # exit
アンマウントする前に、leo の構成ファイルもバックアップしておこう。
(gemini) $ virsh dumpxml leo > /mnt/backup/leo.xml
(gemini) $ cat /mnt/backup/leo.xml
(gemini) $ sudo umount /mnt/backup
(gemini) $ sudo lvchange -a n vg-gfs2/backup

これでバックアップは完了だ。
次こそ色々試してみる。

/etc/libvirt を共有化

前回に続いて、今度は /etc/libvirt を gemini / cancer で共有化してみよう。

複雑なことは無いので、ザクッと。
(gemini) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo lvcreate -n etc-libvirt -L 320M vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo mkfs.gfs2 -t mycluster:virt-define \
-p lock_dlm \
-j 2 \
/dev/vg-gfs2/etc-libvirt
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/etc-libvirt

(gemini) $ sudo mount /dev/vg-gfs2/etc-libvirt /mnt/libvirt
(gemini) $ df /mnt/libvirt

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

(gemini) $ sudo systemctl stop /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo mount /dev/vg-gfs2/etc-libvirt /etc/libvirt
(gemini) $ df /etc/libvirt

これで、leo の起動停止を確認しておく。
動作確認が終わったら、leo は停止しておこう。

(gemini) $ sudo vi /etc/fstab
--ココから
1行書き換え
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
↓
/dev/mapper/vg--gfs2-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで

(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl stop /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo systemctl start /etc/libvirt
(gemini) $ df /etc/libvirt

ここまで来たら、gemini を再起動させ、再起動後に /etc/libvirt がマウントされていることと、leo の起動停止が出来ることを確認しておこう。
(leo は停止しておくこと)

続いて、cancer 側で同ボリュームのマウント。
(cancer) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo lvchange -asy vg-gfs2/etc-libvirt
(cancer) $ sudo lvdisplay vg-gfs2/etc-libvirt
(cancer) $ ls -ld /etc/libvirt
(cancer) $ sudo mv /etc/libvirt /etc/libvirt.orig
(cancer) $ sudo mkdir /etc/libvirt
(cancer) $ sudo mount /dev/vg-gfs2/etc-libvirt /etc/libvirt
(cancer) $ df /etc/libvirt
(cancer) $ ls -ld /etc/libvirt

(cancer) $ sudo vi /etc/fstab
--ココから
1行追加
/dev/mapper/vg--gfs2-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl stop /etc/libvirt
(cancer) $ df /etc/libvirt
(cancer) $ sudo systemctl start /etc/libvirt
(cancer) $ df /etc/libvirt

この状態で一度、virt-manager から cancer の配下を見てみよう。
っと、この状態ではどうやら leo の存在は認識できてないようだ。
libvirt-bin の reload ではどうだろう？
(cancer) $ virsh list --all
(cancer) $ sudo systemctl reload libvirt-bin
(cancer) $ virsh list --all
お、leo が出てきた。
leo のステータスはシャットオフだ。まぁ、gemini 側でも起動していないし。

とりあえず、 cancer を再起動して、もう一度マウント状態と vm の認識状態は確認しておこう。

これで、gemini / cancer 同士で /etc/libvirt を共有することが出来た。
今回はココまでにして、次回以降で leo が gemini / cancer で排他的に起動が可能なこと(同時起動は出来なくて当然)、gemini で稼働中に cancer にオンラインマイグレーション出来るか？等を確認していくことにする。

/var/lib/libvirt を cancer でマウント

続いて、gemini 側で作成した /var/lib/libvirt を、cancer 側でもマウントするようにしよう。
cancer が初めから持っている /var/lib/libvirt は、バックアップ目的でリネームしておく方向で。

(cancer) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgchange -asy vg-gfs2
(cancer) $ sudo mv /var/lib/libvirt /var/lib/libvirt.orig
(cancer) $ sudo mkdir /var/lib/libvirt
(cancer) $ sudo mount /dev/vg-gfs2/var-lib-libvirt /var/lib/libvirt
(cancer) $ df /var/lib/libvirt

この状態で、仮想ディスク状態を見てみよう。
(cancer) $ virsh pool-list --all
(cancer) $ virsh pool-refresh default
(cancer) $ virsh vol-list default
これで、leo.qcow2 が見えるようになった。

virt-manager からも確認が可能だ。

確認できたら、cancer 側も gemini と同様に、自動アクティベートと自動マウントを施す。
(cancer) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
auto_activation_volume_list = [ "cancer-vg" ]
↓
auto_activation_volume_list = [ "cancer-vg", "vg-gfs2" ]
--ココまで

(cancer) $ sudo vi /etc/fstab
--ココから
1行追加
/dev/mapper/vg--gfs2-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで

んで、設定を反映させ、再起動を含めた確認を行う。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl stop /var/lib/libvirt
(cancer) $ df /var/lib/libvirt
(cancer) $ sudo systemctl start /var/lib/libvirt
(cancer) $ df /var/lib/libvirt

(cancer) $ sudo systemctl reboot

(cancer) $ df /var/lib/libvirt
(cancer) $ virsh pool-list --all
(cancer) $ virsh vol-list default

どうやら問題無さそうだ。
次回は、この状態でのライブマイグレーションを確認してみる。

/var/lib/libvirt を共有FS(gfs2)化

というわけで前回の続き。

とりあえず gemini 上で動く仮想マシン(leo)とゲストOS(leo)の作成が完了したところで、とりあえずはその leo の仮想ディスクが入っている /var/lib/libvirt を gemini / cancer で共有しているディスク領域に移すことにする。

ココで既に、/dev/mapper/gfs2-001 という共有領域を作成しているはずなので、これを利用しよう。

ザザッと書いていく。(前回記載した通り、leoは停止しておくこと。)
(gemini) $ sudo pvdisplay /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo lvcreate -L 20G -n var-lib-libvirt vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2

(gemini) $ sudo mkfs.gfs2 -t mycluster:virt-disk \
-p lock_dlm \
-j 2 \
/dev/vg-gfs2/var-lib-libvirt
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/var-lib-libvirt

(gemini) $ sudo mkdir /mnt/libvirt
(gemini) $ sudo mount /dev/vg-gfs2/var-lib-libvirt /mnt/libvirt
(gemini) $ df /mnt/libvirt
(gemini) $ ls -a /mnt/libvirt
(lost+found は存在しないことに注意)

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

(gemini) $ sudo systemctl stop /var/lib/libvirt
(gemini) $ sudo umount /mnt/libvirt
(gemini) $ sudo mount /dev/vg-gfs2/var-lib-libvirt /var/lib/libvirt
(gemini) $ sudo df /mnt/libvirt

この状態で、leo が起動、操作、停止出来ることを確認しておこう。
leo の動作確認がざっと完了したら、leo は停止しておくこと。

続いて、通常マウントを変更する。
(gemini) $ sudo vi /etc/fstab
--ココから
/var/lib/libvirt のマウントを変更しよう。
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
↓
/dev/mapper/vg--gfs2-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl stop /var/lib/libvirt
(gemini) $ df /var/lib/libvirt
(gemini) $ sudo systemctl start /var/lib/libvirt
(gemini) $ df /var/lib/libvirt

あと、vg-gfs2 は OS 起動時に自動アクティベートする設定になっていないので、自動アクティベートするように設定を施す。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
        auto_activation_volume_list = [ "gemini-vg", "vg-kvm" ]
↓
        auto_activation_volume_list = [ "gemini-vg", "vg-kvm", "vg-gfs2" ]
--ココまで

マウント出来ることが確認できたら、gemini を再起動してみる。
(gemini) $ sudo systemctl reboot

再起動後、/var/lib/libvirt がマウントされているようなら、もう一度 leo の起動、動作確認をしてみよう。

問題無さそうなら、そのまま継続だ。(leo は今回停止させない。)

とりあえず、対策を 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

おしまい。

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

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

ちょっとマテよ…(clvmd)

なんてこったい。
clvmパッケージはいくつかのファイルが含まれているけど、起動に関するファイルは主に以下の3つ。

• /etc/init.d/clvm
• /lib/systemd/system/lvm2-clvmd.service
• /lib/systemd/system/lvm2-cluster-activation.service

1つ目が旧来のsysVinitで使用するファイル。残りの2つがsystemdにて使用されるファイルだ。
ただ、1つ目もsystemdによって自動的に読み込まれる。
ただし、毎回起動に失敗している様子だった。

で、中身を読んでみたら…
/etc/init.d/clvm は /usr/sbin/clvmd を起動し、その後にクラスタLVMのアクティベートを行う。
対して /lib/systemd/system/lvm2-clvmd.service が clvmd の起動、
/lib/systemd/system/lvm2-cluster-activation.service が /lib/systemd/lvm2-cluster-activationを起動し、クラスタVGをアクティベートする、という機能だ。
つまり、 /etc/init.d/clvm の持つ2つの機能を、 lvm2-clvmd.service と lvm2-cluster-activation.service の2つで担っているというわけ。
だから、 /etc/init.d/clvm のサービスは起動する必要なし。起動しなくて正解だった。

また余計な時間をかけてしまった…。
--2017/04/20追記ココから--
だったら、 /etc/init.d/clvm は自動起動しないように設定しておけばいいんじゃないかな？
というわけで自動起動から外す。
(gemini) $ systemctl is-enabled clvm
(gemini) $ sudo systemctl disable clvm
(gemini) $ systemctl is-enabled clvm
再起動して確認
(gemini) $ sudo systemctl reboot
(gemini) $ dmesg
(gemini) $ systemctl status clvm
これで大丈夫だろう…。
--2017/04/20追記ココまで--