LVMの自動アクティベートを停止

前回の最後に、「OS起動時に当該LVOLが自動的にアクティベーションされないように設定する」って書いた。
これは、HAクラスタ等を組んでいる場合、共有ボリュームのアクティベーションはOS起動時ではなく、クラスタソフトの方で制御して欲しいからだ。
ただ、今回の構成・目的では、そちらの意味はあまり無い。
共有ファイルシステムを使用しているので、アクティベーションされるのなら共有モードでアクティベーションされて欲しいから、ちょっと使用目的は違う。
のだが、OS起動時の自動アクティベートを調べておきたい、というのが今回の目的。

てっきり、vgchange -aay / -aanというオプションで、自動アクティベートをOn/Off出来ると踏んでいたのだが、どうやら違うようだ。そもそも、-aanというオプションは存在しない模様。

vgchangeのマニュアルを読んでみると、-aay は /etc/lvm/lvm.confのactivation/auto_activation_volume_listに記載されているボリュームを、自動的にアクティベーションする、という意味のようだ。
/etc/fstabに記載されているエントリを一斉にマウントする、mount -a と同じような意味合いか。
逆に、activation/auto_activation_volume_list が未記載の場合は、全てのボリュームをアクティベートしてしまうようだ。

なるほど、システム起動時(OS起動時)にアクティベーションして欲しいボリュームを、activation/auto_activation_volume_list に記載して、アクティベーションして欲しくないボリュームを記載しないことで、OS起動時に自動アクティベートされないようになるようだ。

さっそく実験してみよう。

まずは、当該ボリュームをアンマウント・ディアクティベートしておく。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo systemctl stop /mnt/gfs2
(gemini) $ sudo vgchange -aln vg-ocfs2
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2

一旦再起動して、vg-ocfs2/vg-gfs2が両方共アクティベートされるか確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
lvolがavailableになっているだろうか？

OSを構成するVGの名前を確認しておこう。
(gemini) $ sudo vgs
VG #PV #LV #SN Attr VSize VFree
gemini-vg 1 2 0 wz--n- 72.02g 32.00m
vg-gfs2 1 1 0 wz--nc 10.00g 5.00g
vg-ocfs2 1 1 0 wz--nc 10.00g 5.00g
geminiは、OSインストールメディアのお任せにしていたので、gemini-vgという名前のようだ。

続いて、/etc/lvm/lvm.confを以下のように書き換える。(今回は、vg-gfs2とvg-ocfs2で敢えて変えておく。vg-ocfs2を自動アクティベートされないようにしておく。)
(gemini) $ sudo vi /etc/lvm/lvm.conf
「activation {」で始まる行を探そう。
そのブロックの中に、auto_activation_volume_listの説明文がある。(こちらの環境では、1120行目あたりからだ。)
そのコメント文の下部(こちらの環境では、1156行目あたり)に、以下の行を追記しよう。
--ココから
auto_activation_volume_list = [ "gemini-vg", "vg-gfs2" ]
--ココまで

さて、これでイイのかな？
一旦、両ボリューム(vg-ocfs2/vg-gfs2)をディアクティベートしておく。
(gemini) $ sudo vgchange -aln vg-ocfs2
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2

lvmの設定変更を反映させてみる。(これでいいのかな？)
(gemini) $ sudo systemctl daemon-reload

auto_activateを試してみる。
(gemini) $ sudo vgchange -aay

さてどうなったかな？
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
お、狙ったとおり、vg-ocfs2はディアクティベートのまま、vg-gfs2はアクティベートされたぞ。

じゃ、OS起動時はどうだ？
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo shutdown -r now
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
期待したとおり、vg-ocfs2はディアクティベート、vg-gfs2はアクティベートだ。

これで、自動アクティベートの制御は分かった。
とりあえず、gemini/cancerともに、vg-ocfs2/vg-gfs2は自動アクティベートされないように設定しておこう。
(gemini) $ sudo vi /etc/lvm/lvm.conf
先程追記した行を書き換え。
--ココから
auto_activation_volume_list = [ "gemini-vg", "vg-gfs2" ]
↓
auto_activation_volume_list = [ "gemini-vg" ]
--ココまで
(gemini) $ sudo systemctl daemon-reload

(cancer) $ sudo vgs
VG #PV #LV #SN Attr VSize VFree
cancer-vg 1 2 0 wz--n- 72.02g 32.00m
vg-gfs2 1 1 0 wz--nc 10.00g 5.00g
vg-ocfs2 1 1 0 wz--nc 10.00g 5.00g
OSのvgの名前はcancer-vgのようだ。

(cancer) $ sudo vi /etc/lvm/lvm.conf
1156行目付近に以下の行を追記。
--ココから
auto_activation_volume_list = [ "cancer-vg" ]
--ココまで
(cancer) $ sudo systemctl daemon-reload

さて今回はココまで。
次は、クラスタマーク付き(vgchange -cy)のvgに対してvgdisplayを実行したら表示される「Shared」の意味を調べてみよう。
(正直なところ、結論が出せるか自信がない。)

CLVMに挑戦(アクティベートフラグShared編)

さて前回までで、CLVMのexclusive(排他)モードが使えるようになった。

今回は、shared(共有)モードの検証だ。
(というか、これが、今CLVMを使用したい最大の理由…)

sharedモードにすることで、以下のことが出来るんじゃないかと期待している。

• 複数のノードで同時にアクティベート(これはCLVMじゃなくても出来るけど…)
• VGの構成変更が、関連する全てのノードに自動通知(共有モードじゃなくて、クラスタマークで実現されているんじゃないかな？)
• 全てのノードで受け入れられるVG構成変更でないと、変更がNGになる
• ノード単位でアクティベート・ディアクティベート

目的は、複数のノードで仮想ディスク領域や仮想マシン定義領域を共有し、KVMを動かす、だ。
はっきり言って、これを実行するために、

• 共有ファイルシステム(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関連はオシマイかな？

CLVMに挑戦(アクティベートフラグ編その4)

前回、2ノードクラスタで片系ダウンした時のLVMの操作問題が解決出来た、かのように見える。
でも実際は、まだ問題を抱えている。

以下の手順を実施してみるとその問題に直面する。

1. 両ノード(gemini/cancer)起動。
2. geminiでファイルシステムマウント。
3. cancerを強制停止。(障害を想定)
4. cancerがダウンしている状態で、geminiを再起動。
5. geminiで必要に応じてファイルシステムマウント。

3番までは前回の作業と同じ。
ただ、実際にはcancerの障害が修復しきれないうちに、geminiをメンテナンスで再起動(4)させないといけない、ということは想定できる。
この時、gemini再起動後に正しくファイルシステムマウントが出来ない(5)と思われる。

実際にやってみよう。
まずは両ノード起動していること。
続いて、gemini側でファイルシステムをマウントする。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ sudo lvchange -an vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2

cancerを強制停止させる。(KVMホストから実施)
(sagittarius) $ virsh destroy cancer
(sagittarius) $ virsh list --all

geminiでディスク状態を確認
(gemini) $ df /mnt/ocfs2
(gemini) $ ls -l /mnt/ocfs2
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs

(メンテナンスを想定して)geminiを再起動
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(gemini) $ sudo shutdown -r now

geminiでファイルシステムを使用する
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
ここでハングしてしまう。

このタイミングでは、geminiで当該ディスクが利用できる状態、というのが理想だが、現実はこのような状態。(cancerを起動させれば、geminiでディスクを利用することが出来る。)
これでは、とても不便だ。

で、このあたりを制御するcorosyncパラメータが、wait_for_allだと考えられる。

とりあえず、復帰させるためにcancerを起動させよう。(KVMホスト側から)
(sagittarius) $ virsh start cancer
(sagittarius) $ virsh list --all

とりあえずgeminiでディスクを使っている状態にする。
(cancer) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2

さて、じゃぁcorosyncのwait_for_allについて確認してみよう。
まずはman。
(gemini) $ man 5 votequorum
これを見てみると、以下のことが分かる。

• デフォルトは0
• two_nodeを1に設定すると、wait_for_allも自動的に1に設定される。
  (ただし、別途0にすることは可能。)
• wait_for_allが1になっている場合、全てのノードが同時に稼働状態にならないと、corosyncが稼動状態にならない。
  (wait_for_allが0の場合は、稼動状態のノード数が、ノード全数の過半数に到達した段階でcorosyncが稼働状態になる。)

2ノードクラスタの場合、2ノードとも稼動状態にならないとサービス開始出来ないようだ。
スプリットブレイン発生時等を考えれば、この仕様は正しいと思うけど、これではちょっと運用し辛い。

今回はHAクラスタではなく、使うリソースは共有ファイルシステムだけなので、「両方のノードで同時にサービスが起動して、ファイルシステムが壊れてしまう」等のトラブルは考えなくていい、はず。

であれば、wait_for_allの機能は不要なので、0に変えてみたらどうだろうか…。
どうせ実験環境なので、試してみよう。
両ノード、とりあえずアンマウントとファイルシステムのディアクティベートを実施。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(cancer) $ sudo lvchange -a n vg-ocfs2/lv-ocfs

/etc/corosync/corosync.confを修正
(gemini) $ sudo vi /etc/corosync/corosync.conf
「quorum{}」の中、「two_node: 1」を追記した下に、「wait_for_all: 0」を追記する。
(cancer) $ sudo vi /etc/corosync/corosync.conf
geminiと同様の変更を施す。

設定読み直し。(これで反映されるのかなぁ？)
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl daemon-reload

上で実施したことを試してみよう。
gemini側でファイルシステムをマウントする。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ sudo lvchange -an vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2

cancerを強制停止させる。(KVMホストから実施)
(sagittarius) $ virsh destroy cancer
(sagittarius) $ virsh list --all

geminiでディスク状態を確認
(gemini) $ df /mnt/ocfs2
(gemini) $ ls -l /mnt/ocfs2
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs

(メンテナンスを想定して)geminiを再起動
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(gemini) $ sudo shutdown -r now

geminiでファイルシステムを使用する
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
先程はここでハングしてしまったが、今回は問題なく見える。
この時点ではアクティベートされているが、これは

• 当該lvolは他のノードは掴んでいない
• OS(gemini)は起動時にこのlvolをアクティベートする

の2つの状態のため。(2番目の件は別途検討予定)

とりあえず、排他モードでアクティベートし直して、普通にI/O出来るか確認。
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2
(gemini) $ ls -l /mnt/ocfs2
内容確認出来るので、適当にI/Oしておこう。

問題無さそう。

2ノードクラスタ＆排他制御が必要の場合は、この実装か？
ただ、auto_tie_breakerとauto_tie_breaker_nodeというパラメータも気になる。
調べておきたいけど、後回しでいいかなぁ？

後回しにして、アクティベートフラグのs(-asy/-asn)を実験しよう。

CLVMに挑戦(アクティベートフラグ編その3)

前回、アクティベートフラグの-aeについて実験したんだが、ちょっと期待した結果が得られなかった。

-aeは排他モードを意味していて、HAクラスタ等を使用する時に使えるオプションのはずだ。
通常はメインノードでのみアクティベーションしておいて、メインノードがダウンした時に、スタンバイノードでアクティベーションする。
常にいずれかのノードでのみアクティベーションする形になり、複数のノードで同時にアクティベーション出来ないように制御するのが排他モードのはずだ。

ところが、前回の実験では、メインノードが強制停止した場合に、スタンバイノードでアクティベーションすることが出来ない、という結果になった。

この状況から察するに、クラスタを構成するノードが欠けた場合の挙動が、きちんと設定できていないのではないか？と推測している。

というところで、CLVM(clvmd)は、他のサーバのclvmdと通信をしているはず、という予想ができる。clvmd同士の相互通信によって、共有ボリュームの状態や変更コマンドをやり取りしているのではないか？と考えられる。
ところが、clvmdのセットアップには、特に通信に関わる設定は施していない。
一体どういうことか？

どうやら、clvmdはそれ単独では、他のサーバ上のclvmdと通信をする機能は持っておらず、他のクラスタマネージャの機能を利用しているようだ。
manを見てみると、以下のような記載がある。
--ココから
-I cluster_manager
Selects the cluster manager to use for locking and internal com‐
munications. As it is quite possible to have multiple managers
available on the same system you might have to manually specify
this option to override the search.

By default, omit -I is equivalent to -Iauto. Clvmd will use the
first cluster manager that succeeds, and it checks them in a
predefined order cman, corosync, openais. The available man‐
agers will be listed by order as part of the clvmd -h output.
--ココまで
cman、corosync、openaisのいずれかの機能を利用しているようだ。
また、clvmd -hで何を使っているかが分かるらしい。

(gemini) $ clvmd -h
(一部略)
-I<cmgr> Cluster manager (default: auto)
Available cluster managers: corosync

何も設定していないとautoになり、現在使用可能なクラスタマネージャはcorosyncということになっている。(元々、gfs2のセットアップ時に、corosyncはセットアップしている。)

ということは、以下の図のような関係になっているのではないだろうか？と予想できる。

片方(例えばcancer)がダウンした場合、corosync同士の通信が出来なくなる。
corosync側の設定で、クラスタ構成ノードが欠けた場合の定義をしていれば、もしかしたら…という予想が出来る。

というわけで、corosyncの定義ファイルである、corosync.confのマニュアルを見てみる。
(gemini) $ man 5 corosync.conf
…イマイチ良くわからない。
が、マニュアルエントリの「SEE ALSO」のところに「votequorum(5)」が上がっている。参考情報だ。
voteは「投票」、quorumは「定足数」で、いずれもクラスタ分離(スプリットブレイン等)した時などに必要となるキーワードだ。
今回は、geminiとcancerの2ノードクラスタで、cancerを強制停止した状態なので、クラスタ分離とはちょっと異なるけど、もしかしたらこちらのマニュアルが関係あるかもしれない。

というわけで、そちらのマニュアルも見てみよう。
(gemini) $ man 5 votequorum

お！「SPECIAL FEATURES」の欄に、いきなり「two_node」という宣言の説明がある。
2ノードクラスタの場合に設定する特別なパラメータのようだ。
corosyncの基本ポリシーとしては、クラスタ稼働するためには「クラスタを構成するノード数 / 2 + 1」のノード数が生きている必要がある。
ところが、2ノードクラスタの場合、1台ダウンしたらその時点で条件を満たせなくなるため、2ノードであることを明確に宣言する、ということが必要なようだ。

サンプルに記載があるが、/etc/corosync/corosync.confのquorum{}宣言の中に、「two_node: 1」を追記すればいいようだ。

ただし、付帯事項があって、two_nodeを有効にした場合(1に設定した場合)、合わせてwait_for_allも設定されるようだ。
こちらは、構成されている全ノードが一度でも有効にならないと、クラスタ機能を有効にしない、というパラメータのようだ。
今はまだ「そういうパラメータがある」とだけ覚えておこう。

two_nodeパラメータの効果を確認するために、gemini/cancerの両方のノード上の/etc/corosync/corosync.confを書き換えて、OS毎再起動してみよう。
(もしかしたら、sudo systemctl daemon-reloadでもいいのかもしれないが。)

両方のノードが再起動してきたら、とりあえずLVMの状態から確認していく。
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
再起動直後なので、両方共アクティベートされている。

とりあえずディアクティベートする。
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs

前回の後半と同じ状況を再現してみる。
まずは、cancer側で排他モードでアクティベートする。
(cancer) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs

続いて、cancer側でマウントする。
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ df /mnt/ocfs2

gemini側でディアクティベート出来ないことを確認する
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs

cancerを強制的に停止させる。(KVMホスト側から実施する)
(sagittarius) $ virsh destroy cancer
(sagittarius) $ virsh list --all

生き残っているgemini側からLVのステータスを確認。
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
gemini側からは、ディアクティベートのままとして見える。

ココまでは前回と同じ結果だ。
ココで、gemini側でLVをアクティベートする。
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
あっさりアクティベート出来る。

マウントして、中身を確認してみる。
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ ls -l /mnt/ocfs2
ちゃんと中身が見える。

実際にI/Oしてみると、普通にI/O出来ることが分かる。

というわけで、2ノードクラスタの場合、corosync.confに「two_node: 1」という宣言が必要だったみたいだ。

この状態で、cancer側を起動して、ディスクの付け直し(geminiからcancerへ)が可能かも合わせて確認しておこう。
cancerの起動
(sagittarius) $ virsh start cancer

cancer側で当該ディスクの状態確認。
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
ディアクティベートのままだ。(gemini側で排他モードでアクティベートしているので、これは想定通り)

gemini側でアンマウント、ディアクティベート。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ df /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs

cancer側で排他モードでアクティベート、マウント。
(cancer) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
(cancer) $ ls -l /mnt/ocfs2
普通にマウント出来た。

なんとなくコレでいいような気がするが、もう1つ確認しておく必要がある。
corosync.confにtwo_node宣言を追加する過程で「合わせて、wait_for_allも設定される」と記載した。
このwait_for_allがどのような挙動を示すのか？必要なのか？を確認しておかないといけない。

次回はwait_for_allを確認する。(って、合わせてlast_man_standingやauto_tie_breakerも確認しないといけないっぽいが…)

CLVMに挑戦(アクティベートフラグ編その2)

さて、検証していく過程で、何度かOS再起動が発生する可能性がある。
その都度、OSが共有ボリュームを自動マウントしようとすると、ちょっと不都合が生じる恐れがある。

まずはgemini/cancerの両ノードで、ボリュームの自動マウントが行われないようにしておこう。

まずはgemini/cancerで、アンマウントしておく。
(gemini) $ df
(gemini) $ sudo systemctl stop /mnt/gfs2
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ df

(cancer) $ df
(cancer) $ sudo systemctl stop /mnt/gfs2
(cancer) $ sudo systemctl stop /mnt/ocfs2
(cancer) $ df

続いて、両方のVGのディアクティベート(これは片方のノードで実施すればOK)
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo vgchange -a n vg-gfs2

続いて、OS起動時に自動マウントされないように手を加える。
(gemini) $ sudo vi /etc/fstab
/mnt/ocfs2と/mnt/gfs2のマウントオプションに、noautoを付与する。
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
↓この2行にnoautoを付与
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 noauto,_netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 noauto,_netdev,x-systemd.requires=dlm.service 0 0
--ココまで

(cancer) $ sudo vi /etc/fstab
geminiと同じように修正する。

systemdに変更結果を反映させる。
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl daemon-reload

両ノードを再起動して、マウントされていないかを確認する。
(gemini) $ sudo shutdown -r now
(cancer) $ sudo shutdown -r now

(gemini) $ df
(cancer) $ df

さて、どのようなアクティベートフラグがあるかを確認、という流れだけど、その前に1つ、再起動直後のvg-ocfs2とvg-gfs2の状態を確認しておきたい。
どちらのノードからでも構わない。
(gemini) $ sudo vgdisplay vg-ocfs2
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs

(gemini) $ sudo vgdisplay vg-gfs2
(gemini) $ sudo lvdisplay vg-gfs2/lv-gfs

lvdisplayの出力結果のうち、「LV Status」が、どちらのVGもavailableになっていると思う。
これはOS起動時に、当該LVがアクティベートされた、ということだ。
さて、これはいいことなのだろうか？
一応、現在の挙動はこのようになっている、と言う点は覚えておこう。

で、いよいよアクティベートフラグの確認だ。
lvchangeのmanを見ると、アクティベートに関しては以下のようになっている。
[-a|--activate [a][e|s|l]{y|n}]

また、vgchangeのmanはどうかと言うと…
[-a|--activate   [a|e|s|l]   {y|n}]

微妙に記述は違うが、似たような感じだ。

lvchangeの方のオプション表記は

• aの有無
• e/s/lのいずれかもしくは無し
• yかnのいずれか

のパターンのようだ。
ちょっと複雑だぞ…。(2*4*2=16パターンか？)
でも、マニュアルエントリ上は、以下のパターンしか記載が無いな。

• -a [y|n]
• -aa [y|n]
• -ae [y|n]
• -as [y|n]
• -al [y|n]

vgchangeのマニュアルエントリも同じようだ。

マニュアルを見る限り、以下のような感じになっている。

• -a [y|n]
  activationする、解除する
• -aay
  autoactivationする
  このオプションは、-aanについて言及されてない。なんだ？
• -ae[y|n]
  exclusiveモード(排他モード)でactivationする、解除する
• -as[y|n]
  sharedモード(共有モード)でactivationする、解除する
• -al[y|n]
  当該のノードでのみactivationする、解除する

で、-a、-ae、-asは全てのノードに影響する、ということのようだ。
このあたりは、vgchangeも同じになっている。

一つずつ試してみよう。
まずは、gemini/cancerどちらでもactivateされていることを確認する。
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
「LV Status」が「available」なのを確認。

gemini側でdeactivateする。
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs

gemini/cancerでステータスを確認する。
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
「LV Status」が「NOT available」になったのが確認できたはずだ。

このまま、-aaを確認してみよう。
ただ、autoactivateに関しては、/etc/lvm/lvm.confに記載があるはずなので、コマンドで実行するとなると、どのような変化が現れるか…。
まずは、/etc/lvm/lvm.confをコピっておこう。
(gemini) $ cp -i /etc/lvm/lvm.conf ~/lvm.conf
(cancer) $ cp -i /etc/lvm/lvm.conf ~/lvm.conf

続いて、gemini側で-aaを実行してみる。
(gemini) $ sudo lvchange -aay vg-ocfs2/lv-ocfs

ステータスの確認
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
gemini側は「LV Status」が「available」になった。でもcancer側は「NOT available」のままだ。
違いが分からない…。

(gemini) $ diff ~/lvm.conf /etc/lvm/lvm.conf
(cancer) $ diff ~/lvm.conf /etc/lvm/lvm.conf
差分は無い。

とりあえず、gemini側で-aanをやってみる。
(gemini) $ sudo lvchange -aan vg-ocfs2/lv-ocfs
Invalid argument for --activate: an
Error during parsing of command line.
お？エラーになった。-aanってオプションは無いのか？

gemini側だけactivationされてしまったので、一旦deactivateしておく。
(gemini) $ sudo lvchange -an vg-ocfs2/lv-ocfs

-aayについてはちょっと良く分からなかったので一旦保留。

続いて、-aeだ。
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
これも、gemini側はavailableに変化、cancer側はNOT availableのまま、だ。

排他モードなら、cancer側ではアクティベーション出来ないはずだ。
(cancer) $ sudo lvchange -a y vg-ocfs2/lv-ocfs
Error locking on node UNKNOWN 1084766088: Device or resource busy
Error locking on node 40a83789: Volume is busy on another node
予想通り。

(cancer) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
Error locking on node 40a83789: Volume is busy on another node
こちらも予想通り。

(cancer) $ sudo lvchange -aay vg-ocfs2/lv-ocfs
Error locking on node 40a83789: Volume is busy on another node
同じだ。

cancer側でdeactivate出来るのか？
(cancer) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
あれ？通った。

(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
おっと、「NOT available」になった。

この状態でcancer側で排他モードは使えるのか？
(cancer) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
出来た。

う～む。排他モードでアクティベートした場合、他のノードではアクティベート出来ないが、強制的にディアクティベートすることは可能なのかな？
(gemini側でマウント等していなかったので…。もしgemini側でマウントされていたらどうなるのだろうか？)

というわけで、cancer側でアクティベートされているので、そのままマウントして、gemini側でディアクティベートしかけてみよう。
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
Error locking on node 40a83789: Logical volume vg-ocfs2/lv-ocfs contains a filesystem in use.
なるほど、ファイルシステムを使用しているよ、ということでディアクティベート出来ないのか。

この状態でcancerが強制的にダウンしてしまった場合はどうなんだろう？
KVMホスト側で、cancerを強制的に止めてみる。
(sagittarius) $ virsh destroy cancer
(sagittarius) $ virsh list --all
止まった。

gemini側で仕掛けてみる。
(gemini) $ sudo lvchange -a n vg-ocfs2/lv-ocfs
あれ？反応が無い。ハングした模様…。
とりあえず、もう1セッション開いて、lvchangeのプロセスをkillしておいた。

じゃぁアクティベートは出来るんかいな？
(gemini) $ sudo lvchange -aey vg-ocfs2/lv-ocfs
ダメだな…。
もう一回killしておく。

そもそも、通常のアクティベートは？
(gemini) $ sudo lvchange -a y vg-ocfs2/lv-ocfs
これもダメか…。

じゃぁローカルアクティベートは？
(gemini) $ sudo lvchange -aly vg-ocfs2/lv-ocfs
これもダメ…。

う～ん。これはちょっとマズいねぇ。
排他モードは解除できるのか？
(gemini) $ sudo lvchange -aen vg-ocfs2/lv-ocfs
これもダメ。

っていうか、LVのステータスすら確認できなくなっちゃった。
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs

これだと、HAクラスタでアクティブノードがダウンした時、速やかにスタンバイノードでサービス再開出来ないなぁ。

もう少し調査を進めるにしても、一旦元に戻しておきたいので、cancerを起動して復帰したか確認しよう。
(sagittarius) $ virsh start cancer
(gemini) $ sudo lvdisplay vg-ocfs2/lv-ocfs
(cancer) $ sudo lvdisplay vg-ocfs2/lv-ocfs
「LV Status」が「available」になっているのが確認できた。

長くなったので一旦ココで切る。

CLVMに挑戦(アクティベートフラグ編その1)

LVMはその仕様上、活性化(アクティベート)・非活性化(ディアクティベート)という概念がある。
論理ボリュームを作成しても、アクティベートしないとその論理ボリュームにI/O出来ない、という仕様だ。
LinuxのLVM2では、VGごとアクティベート・ディアクティベートする方法(vgchange -a)の他に、LV(Logical Volume)単位でアクティベート・ディアクティベートする方法(lvchange -a)もある。

Hewlett Packard Enterprise社が販売しているHP-UXというOSでは、LVMのVGにクラスタマークを付与(vgchange -c y)すると、通常のアクティベート(vgchange -a y)が出来なくなり、排他モードという形でしかアクティベート(vgchange -a e)出来なくなる。
また、クラスタマークが付与されている場合、クラスタリングソフトであるServiceGuardが起動していないと、排他モードでもアクティベート出来なくなる。

HAクラスタを構築した場合、複数のノード(サーバ)で同じディスクボリュームをアクティベート出来てしまうと、複数のサーバから同時書き込みが出来ることになる。
それにより、ボリュームの中身が破壊されてしまう可能性があり、ミッションクリティカルな用途ではそのようなリスクは到底許容できない。
HP-UXの場合、そのようなリスクを回避するために、クラスタマークが付与されているVGは、常にひとつのノードでしかアクティベート出来ない仕様になっている。
恐らく、IBM社のAIXでも、同様の仕組みが備わっていると思われる。

サーバA、サーバBが同一の共有ボリュームを持っていた場合、サーバAでそのボリュームをアクティベート、I/Oしていたとして、そのサーバAが障害でダウンした後は、サーバBでそのボリュームをアクティベート、I/Oする、という感じだ。

ただ、時代は既に変わっていて、Oracle社のOracleDB RACのように、「同一ボリュームに対し、複数のサーバが協調しながらI/Oを行う」という要件も出てきた。
そのため、現在のHP-UXのLVMは多分、クラスタマークの付与・アクティベーションのオプションの組み合わせで、複数のノードでアクティベート出来る仕様になっているはずだ。

さて、振り返ってLinux(Ubuntu)はどうか、というと…。
これまで試してきた通り、クラスタマークの有無に関わらず、複数のノード(今回はgemini/cancerの2ノード)で同時にアクティベート出来た。
逆に言うと、「VG/LVの排他制御」が働いていない状態だ。

きっとこれは、本来の使い方とは異なると思う。

そこで、クラスタマークの付与とアクティベートのオプション(フラグ)について再確認しよう、というのが今回から。

実際には次回記事からこの辺りを実験・検証していきたいと思う。

共有FSマウント変更

前回、CLVMが動くところまではナントカしたけど、よく考えてみたらcancer側でファイルシステムマウント関連の設定を施してなかった。

ココとかココとかココとかだ。

これらgeminiに適用した変更内容を、cancer側にも適用しておく必要がある。

というわけで以下の通り。
まずはファイルシステム(/mnt/ocfs2と/mnt/gfs2)がマウントされていないことを確認。
(cancer) $ df
多分、マウントされていないと思うけど、現時点でマウントされていたら、アンマウントしておく必要がある。もしアンマウントに失敗したら、強制再起動しないといけない。

fstabにマウントエントリを書く
(cancer) $ sudo vi /etc/fstab
以下の行を追記する
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで

書き終わったら、設定をsystemdに反映させる。
(cancer) $ sudo systemctl daemon-reload

反映が終わったら、マウント出来るか確認。
(cancer) $ df
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2
(cancer) $ df

マウント出来たのが確認できたら、一応OSを再起動して、再起動後に自動マウントされるか確認。
(cancer) $ sudo shutdown -r now
(cancer) $ df

これでオシマイかと思ったけど、ocfs2の領域がマウントされていない。
gemini側でアクティベートされているのが原因かと思い、色々試してみたんだが、ちょっと原因が不明。

一度、gemini側でアンマウント、ディアクティベート、アクティベート、マウント、の流れを行ったら、cancer側でも問題なくマウント出来るようになった。
もしかしたら、CLVM関連を操作していく過程で、情報の同期が上手く行かなかったのかもしれない。
(gemini) $ df
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo vgchange -a y vg-ocfs2
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ df

本来なら、LVM→CLVM→ファイルシステムという順に作成(操作)していくのを、今回はVG→ファイルシステム→CLVMという順に操作していったため、何か不具合が生じたんじゃないかと。

気になるのなら、gemini/cancerともに停止して、完全停止後に両方を起動して、マウントされるか確認しておいた方がいいかな。

今後、色々実験していく中で、同じような症状が出るかもしれないが、その時にまた考えることにしよう。