22 Cluster Logical Volume Manager (Cluster LVM) #
クラスタ上の共有ストレージを管理する場合、ストレージサブシステムに行った変更を各ノードに伝える必要があります。Logical Volume Manager 2 (LVM2)はローカルストレージの管理に多用されており、クラスタ全体のボリュームグループのトランスペアレントな管理をサポートするために拡張されています。複数のホスト間で共有されるボリュームグループは、ローカルストレージと同じコマンドを使用して管理できます。
22.1 概念の概要 #
Cluster LVMは、さまざまなツールと連携します。
- Distributed Lock Manager (DLM)
クラスタ全体のロックにより、複数のホスト間の共有リソースへのアクセスを調整します。
- Logical Volume Manager (LVM2)
LVM2はディスクスペースの仮想プールを提供し、1つの論理ボリュームを複数のディスクにわたって柔軟に分散できます。
- Cluster Logical Volume Manager (Cluster LVM)
Cluster LVM
という用語は、LVM2がクラスタ環境で使用されていることを示しています。このため、共有ストレージ上のLVM2メタデータを保護するには、ある程度の設定調整が必要になります。SUSE Linux Enterprise 15以降、クラスタ拡張では、よく知られているclvmdの代わりに、lvmlockdを使用します。lvmlockdの詳細については、lvmlockd
コマンドのマニュアルページ(man 8 lvmlockd
)を参照してください。- ボリュームグループと論理ボリューム
ボリュームグループ(VG)と論理ボリューム(LV)は、LVM2の基本的な概念です。ボリュームグループは、複数の物理ディスクのストレージプールです。論理ボリュームはボリュームグループに属し、ファイルシステムを作成できるエラスティックボリュームと見なすことができます。クラスタ環境には、共有VGという概念があります。共有VGは共有ストレージで構成され、複数のホストで同時に使用することができます。
22.2 クラスタLVMの設定 #
以下の要件が満たされていることを確認します。
共有ストレージデバイス(Fibre Channel、FCoE、SCSI、iSCSI SAN、DRBD*などで提供されているデバイス)が使用できること
パッケージ
lvm2
とlvm2-lockd
がインストールされていることを確認します。SUSE Linux Enterprise 15以降では、LVM2クラスタ拡張としてclvmdではなくlvmlockdを使用しています。clvmdデーモンが実行されていないことを確認します。実行されていると、lvmlockdの起動に失敗します。
22.2.1 クラスタリソースの作成 #
クラスタ内で共有VGを設定するには、1つのノードで次の基本手順を実行します。
シェルを起動して、
root
としてログインします。クラスタリソースの現在の設定を確認します。
root #
crm configure showすでにDLMリソース(および対応するベースグループおよびベースクローン)を設定済みである場合、手順22.2「lvmlockdリソースの作成」で継続します。
そうでない場合は、手順18.1「DLMのベースグループの設定」で説明されているように、DLMリソース、および対応するベースグループとベースクローンを設定します。
シェルを起動して、
root
としてログインします。次のコマンドを実行して、このリソースの使用状況を確認します。
root #
crm configure ra info lvmlockdlvmlockd
リソースを次のように設定します。root #
crm configure primitive lvmlockd lvmlockd \ op start timeout="90" \ op stop timeout="100" \ op monitor interval="30" timeout="90"lvmlockd
リソースがすべてのノードで起動されるようにするには、手順22.1「DLMリソースの作成」で作成したストレージ用の基本グループにプリミティブリソースを追加します。root #
crm configure modgroup g-storage add lvmlockd変更内容をレビューします。
root #
crm configure showリソースが正常に実行されているかどうかを確認します。
root #
crm status full
シェルを起動して、
root
としてログインします。すでに2つの共有ディスクがあると仮定し、それらに対して共有VGを作成します。
root #
vgcreate --shared vg1 /dev/sda /dev/sdbLVを作成します。最初は有効にしないでください。
root #
lvcreate -an -L10G -n lv1 vg1
シェルを起動して、
root
としてログインします。次のコマンドを実行して、このリソースの使用状況を確認します。
root #
crm configure ra info LVM-activateこのリソースは、VGのアクティブ化を管理します。共有VGおけるLVアクティブ化には、排他モードと共有モードという2つの異なるモードがあります。デフォルト設定は排他モードです。このモードは通常、
ext4
などのローカルファイルシステムでLVを使用するときに使用します。共有モードは、OCFS2などのクラスタファイルシステムでのみ使用します。VGのアクティブ化を管理するようにリソースを設定します。使用しているシナリオに応じて、次のいずれかのオプションを選択します。
ローカルファイルシステムの使用に対して排他アクティブ化モードを使用します。
root #
crm configure primitive vg1 LVM-activate \ params vgname=vg1 vg_access_mode=lvmlockd \ op start timeout=90s interval=0 \ op stop timeout=90s interval=0 \ op monitor interval=30s timeout=90sOCFS2に対して共有アクティブ化モードを使用し、クローニングされた
g-storage
グループに追加します。root #
crm configure primitive vg1 LVM-activate \ params vgname=vg1 vg_access_mode=lvmlockd activation_mode=shared \ op start timeout=90s interval=0 \ op stop timeout=90s interval=0 \ op monitor interval=30s timeout=90sroot #
crm configure modgroup g-storage add vg1
リソースが正常に実行されているかどうかを確認します。
root #
crm status full
22.2.2 シナリオ: SAN上でiSCSIを使用するCluster LVM #
次のシナリオでは、iSCSIターゲットをいくつかのクライアントにエクスポートする2つのSANボックスを使用します。一般的なアイデアが、図22.1「Cluster LVMを使用した共有ディスクのセットアップ」で説明されています。
以降の手順を実行すると、ディスク上のデータはすべて破壊されます。
まず、1つのSANボックスだけ設定します。各SANボックスは、そのiSCSIターゲットをエクスポートする必要があります。以下に手順を示します。
YaSTを実行し、
› の順にクリックしてiSCSIサーバモジュールを起動します。コンピュータがブートするたびにiSCSIターゲットを起動したい場合は、
を選択し、そうでない場合は、 を選択します。ファイアウォールが実行中の場合は、
を有効にします。新しいiSCSIターゲットを追加します。
ターゲットの名前を入力します。名前は、次のようにフォーマットされます。
iqn.DATE.DOMAIN
フォーマットに関する詳細は、セクション3.2.6.3.1のタイプ「iqn」(iSCSI修飾名)(http://www.ietf.org/rfc/rfc3720.txt)を参照してください。
より説明的な名前にしたい場合は、さまざまなターゲットで一意であれば、識別子を変更できます。
警告ボックスで
を選択して確認します。環境設定ファイル
/etc/iscsi/iscsid.conf
を開き、パラメータnode.startup
をautomatic
に変更します。
次の手順に従って、iSCSIイニシエータを設定します。
YaSTを実行し、
› の順にクリックします。コンピュータがブートするたびに、iSCSIイニシエータを起動したい場合は、
を選択し、そうでない場合は、 を選択します。IPアドレスとiSCSIターゲットのポートを追加します(手順22.5「iSCSIターゲット(SAN上)を設定する」参照)。通常は、ポートを既定のままにし、デフォルト値を使用できます。
認証を使用する場合は、受信および送信用のユーザ名およびパスワードを挿入します。そうでない場合は、
を選択します。シェルを開いて、
root
としてログインします。iSCSIイニシエータが正常に起動しているかどうかテストします。
root #
iscsiadm
-m discovery -t st -p 192.168.3.100 192.168.3.100:3260,1 iqn.2010-03.de.jupiter:san1セッションを確立します。
root #
iscsiadm
-m node -l -p 192.168.3.100 -T iqn.2010-03.de.jupiter:san1 Logging in to [iface: default, target: iqn.2010-03.de.jupiter:san1, portal: 192.168.3.100,3260] Login to [iface: default, target: iqn.2010-03.de.jupiter:san1, portal: 192.168.3.100,3260]: successfullsscsi
でデバイス名を表示します。... [4:0:0:2] disk IET ... 0 /dev/sdd [5:0:0:1] disk IET ... 0 /dev/sde
3番目の列に
IET
を含むエントリを捜します。この場合、該当するデバイスは、/dev/sdd
と/dev/sde
です。
手順22.6「iSCSIイニシエータの環境設定」のiSCSIイニシエータを実行したノードの1つで、
root
シェルを開きます。ディスク
/dev/sdd
および/dev/sde
に共有ボリュームグループを作成します。root #
vgcreate --shared testvg /dev/sdd /dev/sde必要に応じて、論理ボリュームを作成します。
root #
lvcreate
--name lv1 --size 500M testvgボリュームグループを
vgdisplay
で確認します。--- Volume group --- VG Name testvg System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 1016,00 MB PE Size 4,00 MB Total PE 254 Alloc PE / Size 0 / 0 Free PE / Size 254 / 1016,00 MB VG UUID UCyWw8-2jqV-enuT-KH4d-NXQI-JhH3-J24anD
コマンド
vgs
を使用してボリュームグループの共有状態を確認します。root #
vgs
VG #PV #LV #SN Attr VSize VFree vgshared 1 1 0 wz--ns 1016.00m 1016.00mAttr
列には、ボリューム属性が表示されます。この例では、ボリュームグループは書き込み可能(w
)、サイズ変更可能(z
)であり、割り当てポリシーは通常(n
)であり、共有リソース(s
)です。詳細については、vgs
のマニュアルページを参照してください。
ボリュームを作成してリソースを起動したら、/dev/testvg
の下に、新しいデバイス名(/dev/testvg/lv1
など)を作成する必要があります。これは、LVがアクティブ化され使用できることを示します。
22.2.3 シナリオ: DRBDを使用したCluster LVM #
市、国、または大陸の各所にデータセンターが分散している場合は、次のシナリオを使用できます。
プライマリ/プライマリDRBDリソースを作成する
まず、手順21.1「DRBDの手動設定」の説明に従って、DRBDデバイスをプライマリ/セカンダリとしてセットアップします。ディスクの状態が両方のノードで
up-to-date
であることを確認します。drbdadm status
を使用してこれをチェックします。次のオプションを環境設定ファイル(通常は、
/etc/drbd.d/r0.res
)に追加します。resource r0 { net { allow-two-primaries; } ... }
変更した設定ファイルをもう一方のノードにコピーします。たとえば、次のように指定します。
root #
scp
/etc/drbd.d/r0.res venus:/etc/drbd.d/両方のノードで、次のコマンドを実行します。
root #
drbdadm
disconnect r0root #
drbdadm
connect r0root #
drbdadm
primary r0ノードのステータスをチェックします。
root #
drbdadm
status r0
lvmlockdリソースをペースメーカーの環境設定でクローンとして保存し、DLMクローンリソースに依存させます。詳細については、手順22.1「DLMリソースの作成」を参照してください。次に進む前に、クラスタでこれらのリソースが正しく機動していることを確認してください。
crm status
またはWebインタフェースを使用して、実行中のサービスを確認します。pvcreate
コマンドで、LVM用に物理ボリュームを準備します。たとえば、/dev/drbd_r0
デバイスでは、コマンドは次のようになります。root #
pvcreate
/dev/drbd_r0共有ボリュームグループを作成します。
root #
vgcreate
--shared testvg /dev/drbd_r0必要に応じて、論理ボリュームを作成します。おそらく、論理ボリュームのサイズの変更が必要になります。たとえば、次のコマンドで、4GBの論理ボリュームを作成します。
root #
lvcreate
--name lv1 -L 4G testvgVG内の論理ボリュームは、ファイルシステムのマウントまたはraw用として使用できるようになりました。論理ボリュームを使用しているサービスにコロケーションのための正しい依存性があることを確認し、VGをアクティブ化したら論理ボリュームの順序付けを行います。
このような設定手順を終了すると、LVM2の環境設定は他のスタンドアロンワークステーションと同様に行えます。
22.3 有効なLVM2デバイスの明示的な設定 #
複数のデバイスが同じ物理ボリュームの署名を共有していると思われる場合(マルチパスデバイスやDRBDなどのように)、LVM2がPVを走査するデバイスを明示的に設定しておくことをお勧めします。
たとえば、コマンドvgcreate
で、ミラーリングされたブロックデバイスを使用する代わりに物理デバイスを使用すると、DRBDで混乱が生じます。これにより、DRBDがスプリットブレイン状態になる可能性があります。
LVM2用の単一のデバイスを非アクティブ化するには、次の手順に従います。
ファイル
/etc/lvm/lvm.conf
を編集し、filter
から始まる行を検索します。そこに記載されているパターンは正規表現として処理されます。冒頭の「a」は走査にデバイスパターンを受け入れることを、冒頭の「r」はそのデバイスパターンのデバイスを拒否することを意味します。
/dev/sdb1
という名前のデバイスを削除するには、次の表現をフィルタルールに追加します。"r|^/dev/sdb1$|"
完全なフィルタ行は次のようになります。
filter = [ "r|^/dev/sdb1$|", "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "a/.*/" ]
DRBDとMPIOデバイスは受け入れ、その他のすべてのデバイスは拒否するフィルタ行は次のようになります。
filter = [ "a|/dev/drbd.*|", "a|/dev/.*/by-id/dm-uuid-mpath-.*|", "r/.*/" ]
環境設定ファイルを書き込み、すべてのクラスタノードにコピーします。
22.4 Mirror LVからCluster MDへのオンラインマイグレーション #
SUSE Linux Enterprise High Availability Extension 15以降、Cluster LVMでのcmirrord
の使用は非推奨になりました。クラスタ内のミラー論理ボリュームはCluster MDに移行することを強く推奨します。Cluster MDはクラスタマルチデバイスの略称で、クラスタ用のソフトウェアベースのRAIDストレージソリューションです。
22.4.1 マイグレーション前のサンプルセットアップ #
次のサンプルセットアップが存在するとします。
alice
およびbob
というノードからなる2ノードクラスタcluster-vg2
というボリュームグループから作成された、test-lv
という名前のミラー論理ボリューム/dev/vdb
および/dev/vdc
というディスクからなるボリュームグループcluster-vg2
root #
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 40G 0 disk ├─vda1 253:1 0 4G 0 part [SWAP] └─vda2 253:2 0 36G 0 part / vdb 253:16 0 20G 0 disk ├─cluster--vg2-test--lv_mlog_mimage_0 254:0 0 4M 0 lvm │ └─cluster--vg2-test--lv_mlog 254:2 0 4M 0 lvm │ └─cluster--vg2-test--lv 254:5 0 12G 0 lvm └─cluster--vg2-test--lv_mimage_0 254:3 0 12G 0 lvm └─cluster--vg2-test--lv 254:5 0 12G 0 lvm vdc 253:32 0 20G 0 disk ├─cluster--vg2-test--lv_mlog_mimage_1 254:1 0 4M 0 lvm │ └─cluster--vg2-test--lv_mlog 254:2 0 4M 0 lvm │ └─cluster--vg2-test--lv 254:5 0 12G 0 lvm └─cluster--vg2-test--lv_mimage_1 254:4 0 12G 0 lvm └─cluster--vg2-test--lv 254:5 0 12G 0 lvm
マイグレーション手順を実施する前に、論理ボリュームおよび物理ボリュームで使用可能な容量と、どの程度使用されているかを確認してください。論理ボリュームの容量がすべて使い果たされている場合、マイグレーションは失敗し、ターゲットボリュームに関するinsufficient free space
エラーが発生します。こうしたマイグレーション障害に対応するための回避策は、ミラーログのオプションに応じて異なります。
ミラーログ自体が(
mirrored
オプションを使用して)ミラーリングされ、ミラーログの格納先と同じデバイスに割り当てられている場合. (たとえば、SUSE Linux Enterprise High Availability Extension 11または12で、各バージョンの 『管理ガイド』の説明に従って、cmirrord
を設定した論理ボリュームを作成したケース。)デフォルトでは、
mdadm
が実行されることにより、デバイスとアレイデータのマイグレーションがそれぞれ開始される前に、ある程度の空き領域が確保されます。マイグレーション中には、この未使用のパディング領域をチェックして、その容量を削除することも可能です。その際には、ステップ 1.dと次の段落で説明するdata-offset
オプションを利用できます。data-offset
の実行時には、Cluster MDがそのメタデータを書き込めるよう、デバイス上に十分な余裕を持たせる必要があります。一方で、オフセット自体の容量は抑える必要があります。デバイスの残りの領域で、移行する物理ボリュームのエクステントをすべて格納しなければならないからです。使用可能なボリューム領域は、ボリューム全体からミラーログを差し引いた残りの領域なので、オフセットのサイズはミラーログよりも小さくする必要があります。data-offset
を128kBに設定することを推奨します。オフセット値を指定しない場合、デフォルト値の1kB (1024バイト)が使用されます。ミラーログが(
disk
オプションを使用して)別のデバイスに記録されている場合、あるいは(core
オプションを使用して)メモリ上に格納されている場合: マイグレーションを始める前に、物理ボリュームの容量を増やすか、(物理ボリュームの空き領域を確保するために)論理ボリュームのサイズを減らします。
22.4.2 Mirror LVをCluster MDにマイグレートする #
以下の手順は、22.4.1項 「マイグレーション前のサンプルセットアップ」に基づいています。セットアップ環境に応じて手順を変更し、LV、VG、ディスク、Cluster MDデバイスの名前はご使用のリソースに置き換えてください。
このマイグレーションではダウンタイムは発生しません。そのため、マイグレーション中でもファイルシステムをマウントすることができます。
alice
ノードで、次の手順を実行します。ミラー論理ボリューム
test-lv
をリニア論理ボリュームに変換します。root #
lvconvert -m0 cluster-vg2/test-lv /dev/vdc物理ボリューム
/dev/vdc
をボリュームグループcluster-vg2
から削除します。root #
vgreduce cluster-vg2 /dev/vdcこの物理ボリュームをLVMから削除します。
root #
pvremove /dev/vdclsblk
を実行すると、次のように出力されます。NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 40G 0 disk ├─vda1 253:1 0 4G 0 part [SWAP] └─vda2 253:2 0 36G 0 part / vdb 253:16 0 20G 0 disk └─cluster--vg2-test--lv 254:5 0 12G 0 lvm vdc 253:32 0 20G 0 disk
ディスク
/dev/vdc
を持つCluster MDデバイス/dev/md0
を作成します。root #
mdadm --create /dev/md0 --bitmap=clustered \ --metadata=1.2 --raid-devices=1 --force --level=mirror \ /dev/vdc --data-offset=128data-offset
オプションを使用する理由については、重要: マイグレーションにおける障害の発生を避けるを参照してください。
bob
ノードで、次のMDデバイスをアセンブルします。root #
mdadm --assemble md0 /dev/vdc2ノードより多いクラスタでは、クラスタ内の残りのノードについても、この手順を実行してください。
alice
ノードに戻って、次の手順を実行します。LVM用の物理ボリュームとして、MDデバイス
/dev/md0
を初期化します。root #
pvcreate /dev/md0MDデバイス
/dev/md0
をボリュームグループcluster-vg2
に追加します。root #
vgextend cluster-vg2 /dev/md0ディスク
/dev/vdb
のデータをデバイス/dev/md0
に移動します。root #
pvmove /dev/vdb /dev/md0物理ボリューム
/dev/vdb
をボリュームgroup cluster-vg2
から削除します。root #
vgreduce cluster-vg2 /dev/vdbLVMがデバイスを物理ボリュームとして認識しなくなるように、このデバイスのラベルを削除します。
root #
pvremove /dev/vdb/dev/vdb
をMDデバイス/dev/md0
に追加します。root #
mdadm --grow /dev/md0 --raid-devices=2 --add /dev/vdb
22.4.3 マイグレーション後のサンプルセットアップ #
lsblk
を実行すると、次のように出力されます。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 40G 0 disk ├─vda1 253:1 0 4G 0 part [SWAP] └─vda2 253:2 0 36G 0 part / vdb 253:16 0 20G 0 disk └─md0 9:0 0 20G 0 raid1 └─cluster--vg2-test--lv 254:5 0 12G 0 lvm vdc 253:32 0 20G 0 disk └─md0 9:0 0 20G 0 raid1 └─cluster--vg2-test--lv 254:5 0 12G 0 lvm
22.5 詳細の参照先 #
lvmlockdの詳細については、lvmlockd
コマンドのマニュアルページ(man 8 lvmlockd
)を参照してください。
詳細な情報は、http://www.clusterlabs.org/wiki/Help:ContentsにあるPacemakerメーリングリストから取得できます。