今回は、shared(共有)モードの検証だ。
(というか、これが、今CLVMを使用したい最大の理由…)
sharedモードにすることで、以下のことが出来るんじゃないかと期待している。
- 複数のノードで同時にアクティベート(これはCLVMじゃなくても出来るけど…)
- VGの構成変更が、関連する全てのノードに自動通知(共有モードじゃなくて、クラスタマークで実現されているんじゃないかな？)
- 全てのノードで受け入れられるVG構成変更でないと、変更がNGになる
- ノード単位でアクティベート・ディアクティベート
はっきり言って、これを実行するために、
- 共有ファイルシステム(ocfs2/gfs2)
- 共有ボリュームマネージャ(CLVM)
というわけで、まずは準備だ。
前回停止しっぱなしのcancerの起動。(KVMホストから)
(sagittarius) $ virsh start cancer
(sagittarius) $ virsh list --all
両ノードで、ファイルシステムアンマウントとディアクティベート。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aen vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(gemini) $ sudo vgdisplay vg-ocfs2
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo vgdisplay vg-ocfs2
ここから本番。
共有アクティベートしてみる。
(gemini) $ sudo lvchange -asy vg-ocfs2/lv-ocfs
(gemini) $ sudo vgdisplay vg-ocfs2
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
両ノードでアクティベートされている。
ちょっとノード単位のアクティベート・ディアクティベートを試してみよう。
(gemini) $ sudo lvchange -aln vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
geminiだけディアクティベートされた。
(gemini) $ sudo lvchange -aly vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
両ノードでアクティベート状態だ。
(gemini) $ sudo lvchange -an vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
両ノードでディアクティベート。
(gemini) $ sudo lvchange -aly vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
gemini側だけアクティベート。
(cancer) $ sudo lvchange -aly vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
cancer側でもアクティベートされた。(両ノードでアクティベート)
両ノードでマウントしてみる。
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
マウント出来る。
う～ん。なんか、sharedモードって、普通の(モードフラグを付けない)場合と同じ挙動だなぁ。
ちょっと、sharedモードとexcusiveモードの競合を試してみよう。
sharedモードでアクティベートされていたら、exclusiveモードではアクティベート出来ないはずだ。
まずはcancer側でアンマウント、ディアクティベート。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
(cancer) $ sudo lvchange -aln vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
gemini側でも状態を確認しておこう。(マウントしているので、ディアクティベートはされていないはず。)
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
cancer側でexclusiveモードでアクティベート。
(cancer) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
Error locking on node 40a83789: Volume is busy on another node
やっぱりエラーになった。予想通り。
とりあえず、cancer側でアクティベートとマウントしておこう。
(cancer) $ sudo lvchange -asy vg-ocfs2/lv-ocfs
(-asyでも-alyでも同じようだ…)
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
さて、続いてCLVMで期待している機能の確認だ。
geminiにのみディスクを追加し、gemini/cancer両方で共有しているvg(vg-gfs2/vg-ocfs2)に対し、そのディスクで拡張処理をしてみたいと思う。
ここでは、エラーになって拡張できない結果になるのを期待している。
まずは、KVMホストからvirt-managerを起動し、geminiに10GB程度のディスクを追加しよう。(接続方式はvirt-io形式にした)
追加出来たら、gemini側でデバイスの確認だ。
(gemini) $ dmesg
あれ？dmesgではデバイス名が分からない？
(gemini) $ ls -l /dev/vd*
/dev/vddというデバイスが追加されている。これが新しく足したデバイスだろう。
(gemini) $ lsblk
vddは何も使用されていないディスクだ。
さて、こいつをvg-ocfs2に拡張してみよう。
まずはパーティションの作成。(パーティションを作る必要は無いんだけどね。)
(gemini) $ sudo parted /dev/vdd print
(gemini) $ sudo parted /dev/vdd mklabel gpt
(gemini) $ sudo parted /dev/vdd print
(gemini) $ sudo parted /dev/vdd mkpart primary 0% 100%
(gemini) $ sudo parted /dev/vdd print
(gemini) $ sudo parted /dev/vdd set 1 lvm on
(gemini) $ sudo parted /dev/vdd print
続いて、pvの作成
(gemini) $ sudo pvcreate /dev/vdd1
で、vg-ocfs2に今作成したpvを追加してみる。
まずはテストモードで実行。
(gemini) $ sudo vgextend -t vg-ocfs2 /dev/vdd1
あれ？出来てしもーた。
まさか…
(gemini) $ sudo vgextend vg-ocfs2 /dev/vdd1
出来ちゃったよ…？？？
(gemini) $ sudo vgdisplay -v vg-ocfs2
確かに、vdb1とvdd1で構成されているし、容量も約20GBある…。
これだと、cancer側でどう見えるんだ…？
(cancer) $ sudo vgdisplay -v vg-ocfs2
おっと、なるほど。見えないデバイスが使われている、ということでgemini側では/dev/vdd1と表示されているところが「unknown device」と表示されるのか。
ちょっとこれではマズイなぁ。
いや、違うか…。今回はcancerを起動しっぱなしで、gemini側を操作したので、gemini/cancer間でディスクの状態を相互確認してくれると思っていたんだけど、よく考えてみたら、必ずクラスタノードが全て生きている、とは限らないのか。
その状態でも、生きているノードにディスクを拡張する、というアクションが起きないとは限らない。
であれば、今回cancerがダウンしていても、gemini側で操作が完結出来ないといけないか。
とすれば、vg拡張後、必要な各ノードで全てvgdisplayを実行して、各ノードがディスクを正しく認識しているか確認する、という手作業が必要だ、ということだな。
壊れることを覚悟して、ofs2のlvol(vg-ocfs2/lv-ocfs)を、新しく追加したpv(/dev/vdd1)に拡張してみよう。
(gemini) $ sudo lvextend -L+1G -v vg-ocfs2/lv-ocfs /dev/vdd1
Finding volume group vg-ocfs2
Archiving volume group "vg-ocfs2" metadata (seqno 4).
Extending logical volume vg-ocfs2/lv-ocfs to 6.00 GiB
Size of logical volume vg-ocfs2/lv-ocfs changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
Error locking on node 40a83789: Aborting. LV lv-ocfs is now incomplete and '--activationmode partial' was not specified.
Failed to lock logical volume vg-ocfs2/lv-ocfs.
おっと！エラーになったぞ！
そうか、VGレベルではエラーにならず、LVレベルでエラーになるのか。
ここで更に実験だ。
対向ノードであるcancerで/dev/vdd1が見えていないから、そのlvolの拡張に失敗したわけだけど、cancerがダウンしていたらどうなんだろうか？
というわけで、cancerを停止してみる。
普通にシャットダウンでいいぞ。
(cancer) $ sudo shutdown -h now
cancerが停止したら、gemini側で先程と同様、LVを拡張してみる。
(gemini) $ sudo lvextend -L+1G -v vg-ocfs2/lv-ocfs /dev/vdd1
今度は成功したようだ。
確認してみよう。
(gemini) $ sudo vgdisplay -v vg-ocfs2
lv-ocfsは6GBまで拡張されていて、/dev/vdd1もPEを消費している。
ふむ。この状態でcancerを起動、当該ボリュームをアクティベートしようとしたら、当然エラーになるはずだよな。
cancerの起動(KVMホストから)
(sagittarius) $ virsh start cancer
(sagittarius) $ virsh list --all
cancerで当該LVMの状態確認。
(cancer) $ sudo vgdisplay -v vg-ocfs2
先程と同様、pvが1つ見えない状態だ。
lvolもアクティベートされていない。
んじゃぁ、lvolアクティベート(エラーになるはず。)
(cancer) $ sudo lvchange -asy vg-ocfs2/lv-ocfs
Couldn't find device with uuid 9Vn0Br-4wpP-gYLm-YOfe-6SK8-B6qx-H2D0n4.
Error locking on node 40a83789: Refusing activation of partial LV vg-ocfs2/lv-ocfs. Use '--activationmode partial' to override.
エラーになったな。ん？「Use '--activationmode partial'」というアドバイスも出た。
なるほど、何らかの要因で、lvolを構成するボリュームが足りない場合、--activationmode partialというオプションを使うことも可能か。
だけどこの場合、
- ミラーlvolが片肺運転
- raid5で構成されたlvolで、1つだけpvが見えない場合
では、cancerからは見えないディスクを、cancer側にも見せたらどうなるんだろうか？
KVMホストのvirt-managerから、geminiに追加したディスクを、cancer側にも接続してみよう。(ワーニングが出るが無視してOK)
さっそく、cancerで確認だ。
(cancer) $ sudo lvchange -asy vg-ocfs2/lv-ocfs
Error locking on node 40a83789: Refusing activation of partial LV vg-ocfs2/lv-ocfs. Use '--activationmode partial' to override.
あれ？エラーになった。
LVM構成情報が同期取れてないんじゃないかな？
ディスク関係を再度チェック。
(cancer) $ dmesg
(cancer) $ ls -l /dev/vd*
(cancer) $ lsblk
(cancer) $ sudo vgscan -v
もう一度アクテイベート
(cancer) $ sudo lvchange -asy vg-ocfs2/lv-ocfs
出来た。
どうやら、共有化(クラスタ化)することで出て来る制約は、vgレベルで制御かかるかと思ったんだけど、lvレベルで制御がかかるのね。
個人的にはちょっと遅い気がするけど、そういうもの、と思って運用していけばいいだけか。
もう少し実験していく。今度は両ノードが生きている状態で、lvの縮小とpvの削除だ。
cancer側でマウント出来ていないはずなので、先にマウントしておく。
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
続いて、lvの縮小。(ファイルシステム自体は拡張していないので、ファイルシステム操作は今回不要だ。)
(gemini) $ sudo lvreduce -L-1G vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
lvdisplayの出力結果のうち、Segumentsが2から1に減っているはずだ。
これは、「いくつのPVにまたがっているか？」という情報で、今まではこのlvolは/dev/vdb1と/dev/vdd1の両方にまたがっていた。
これが、/dev/vdb1のみに縮小されたため、Segmentsも1になった、というわけだ。
もし、Segmentsが2のままだったら、pvmoveコマンド等で、使用している領域を/dev/vdb1に集め直さないと行けない。
今回は/dev/vdb1に集まったので、pvmoveは不要だ。
次は、vg-ocfs2から/dev/vdd1を切り離す。
念のため、/dev/vdd1の領域が未使用なのを確認する。
(gemini) $ sudo pvdisplay /dev/vdd1
(cancer) $ sudo pvdisplay /dev/vdd1
Total PEとFree PEの値が同じで、Allocated PEが0なら、このPVはどのLVにも割当たってない、ということだ。
というわけで、vg-ocfs2から/dev/vdd1を切り離そう。
テストモードから。
(gemini) $ sudo vgreduce -t -v vg-ocfs2 /dev/vdd1
問題無さそうだ。
では実際に実行。
(gemini) $ sudo vgreduce -v vg-ocfs2 /dev/vdd1
成功したか確認してみよう。
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo pvdisplay -v /dev/vdd1
cancer側にも反映されているか確認。
(cancer) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo pvdisplay -v /dev/vdd1
切り離し成功。
とりあえず、このディスクは一旦使わないので、切り落としてしまおう。
PV情報の削除。
(gemini) $ sudo pvremove /dev/vdd1
(gemini) $ sudo pvdisplay /dev/vdd1
(cancer) $ sudo pvdisplay /dev/vdd1
パーティションの削除。
(gemini) $ sudo parted /dev/vdd print
(gemini) $ sudo parted /dev/vdd rm 1
(gemini) $ sudo parted /dev/vdd print
(cancer) $ sudo partprobe /dev/vdd
(cancer) $ sudo parted /dev/vdd print
(cancer) $ ls -l /dev/vdd*
ディスクデバイスの削除。(virtioデバイスの場合の記述。virtioではなく、仮想SCSIの場合は、この辺りに記載しているので参考に。)
(gemini) $ ls -l /sys/block/vdd/device
virtio6へのシンボリックリンクであることを確認。
(gemini) $ sudo bash -c "echo virtio6 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(gemini) $ ls -l /dev/vdd*
(gemini) $ lsblk
vddが無くなったはずだ。
同様にcancerも。
(cancer) $ ls -l /sys/block/vdd/device
こちらもvirtio6だ。
(cancer) $ sudo bash -c "echo virtio6 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(cancer) $ ls -l /dev/vdd*
両OSからデバイスを削除したら、KVMホストからもvirt-managerを使って、当該ディスクを外しておこう。
今回、がっつり長くなってしまった。
Shared関係を一気に書いてしまったからだ。
ただ、ずっと気になっている点がある。
clusterマークを付与したvgに対し、vgdisplayを実行すると、Clusterdはyesと出るが、Sharedがnoのまま。
これ、何のフラグなんだろうか？
結構重要なポイントな気がしてならない。
次回はまず、OS起動時に当該LVOLが自動的にアクティベーションされないように設定するのを目指し、その次に、このvgdisplayのSharedステータスを調査したい。
ここまでやったら、CLVM関連はオシマイかな？
0 件のコメント:
コメントを投稿