LinuCレベル4 システムアーキテクト ネットワークとストレージの選定 問20
ネットワークとストレージの選定／集中型および分散型ストレージ3台のKVMホストがFC SAN上の同じLUNを共有し、その上のLVMの論理ボリューム（LV）を仮想マシンのディスクとして使う。どのホストからでも新しいLVを作成できるようにしたく、1つのLVを同時に2台のホストで使って仮想マシンのディスクを壊す事態は防ぎたい。LVMの設計として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「ネットワークとストレージの選定」に対応。実際の試験問題ではありません）
- A各ホストで通常のローカルのボリュームグループとして同じLUNを認識させ、LVの作成は同時に行わないよう運用手順で管理する
- BLUN上の1つのLVにXFSを作って全ホストで同時にマウントし、各仮想マシンのディスクをイメージファイルとして置く
- Clvmlockdによる共有ボリュームグループとし、ホスト間でメタデータの更新をロックし、LVは使うホストで排他的に活性化する
- Dロックの仕組みは使わず、各ホストがLVMのメタデータを定期的に読み直すことで、他ホストでの作成や拡張を反映させる
正解：C
解説
複数のホストから同じボリュームグループを使う場合は、LVMのメタデータの更新とLVの活性化をホスト間で調停する仕組みが必要です。かつてはclvmd（cLVM）が使われていましたが、RHEL 8以降などの現行のディストリビューションでは、lvmlockdとロックマネージャ（dlmまたはsanlock）による共有ボリュームグループがその役割を担います。共有ボリュームグループでは、LVを排他モードで活性化すると他のホストでは活性化できなくなるため、1つのLVを複数のホストが同時に使う事故を防げます。ロックなしで同じPVを複数ホストから扱うと、メタデータの食い違いやデータ破損の原因になります。
選択肢ごとの解説
- A誤り。ローカルのボリュームグループは他のホストによる変更を想定しておらず、各ホストのメタデータの認識が食い違ってボリュームグループを壊すおそれがあります。運用手順だけでは同じLVの同時利用も防げません。
- B誤り。XFSは複数のホストからの同時マウントに対応しないため、ファイルシステムが壊れます。複数ホストで同時にマウントするならGFS2などのクラスタファイルシステムが必要です。
- C正しい。lvmlockdがホスト間でメタデータの更新とLVの活性化を調停するので、どのホストからでもLVを作成でき、排他的な活性化で同じLVの同時利用を防げます。
- D誤り。メタデータを読み直すだけでは、複数のホストが同時に更新したときの競合を防げません。LVの活性化も調停されないため、同じLVを2台で使う事故も防げません。