Show Table of Contents
4.4.3. ミラー化ボリュームの作成
注記
Red Hat Enterprise Linux 6.3 リリースは、LVM は RAID4/5/6 およびミラーリングの新たな実装をサポートしています。この新しい実装の詳細については、「RAID 論理ボリューム」 を参照してください。
注記
ミラー化された LVM 論理ボリュームをクラスター内に作成するには、単一ノード上でミラー化論理ボリュームを作成するのと同じコマンドと手順が必要です。しかし、クラスター内にミラー化 LVM ボリュームを作成するには、クラスターとクラスターミラーインフラストラクチャーが稼動中であり、クラスターが定足数に達しており、かつクラスターロッキングを有効化するように
lvm.conf ファイル内のロッキングタイプが正しく設定されている必要があります。クラスター内におけるミラー化ボリューム作成の例については、「クラスター内でのミラー化 LVM 論理ボリュームの作成」 を参照してください。
単一クラスター内の複数のノードから短時間に連続して複数の LVM ミラー作成および変換コマンドを実行しようとすると、これらのコマンドのバックログが生じる場合があります。これによって、要求した動作がタイムアウトになり、その後に失敗する可能性があります。この問題を回避するために、クラスターミラー作成コマンドをそのクラスターの単一ノードから実行することを推奨します。
ミラー化ボリュームを作成する場合、
lvcreate コマンドの -m 引数を使用して、作成するデータのコピー数を指定します。-m1 を指定すると、1 つのミラーが作成され、ファイルシステムのコピーが合計 2 つとなります (1 つのリニア論理ボリュームと 1 つのコピー)。同様に -m2 を指定すると、2 つのミラーが作成され、ファイルシステムのコピーが合計 3 つになります。
以下のコマンドは、単一のミラーを持つミラー化論理ボリュームを作成します。ボリュームは、サイズは 50 ギガバイトで、名前は
mirrorlv であり、ボリュームグループ vg0 から構築されます。
# lvcreate -L 50G -m1 -n mirrorlv vg0
デフォルトで LVM ミラーデバイスは、コピーされるデバイスをサイズが 512KB のリージョンに分割します。
lvcreate コマンドで -R 引数を使用して、リージョンサイズをメガバイト単位で指定できます。また、lvm.conf ファイル内の mirror_region_size 設定を編集して、デフォルトのリージョンサイズを変更することも可能です。
注記
クラスターインフラストラクチャーの制限により、デフォルトのリージョンサイズが 512KB では、1.5TB を超えるクラスターミラーは作成できません。1.5TB よりも大きなミラーを必要とするユーザーは、リージョンサイズをデフォルトよりも大きくする必要があります。リージョンサイズを大きくしておかないと、LVM の作成がハングしてしまい、またその他の LVM コマンドもハングしてしまう可能性もあります。
1.5TB を超えるミラー用のリージョンサイズを指定するための一般的なガイドラインとして、ミラーサイズをテラバイト単位で捉えて、2 の次の累乗に切り上げ、その数を
lvcreate コマンドの -R 引数として使用することができます。たとえば、ミラーサイズが 1.5TB の場合、-R 2 と指定することができます。また、ミラーサイズが 3TB の場合は -R 4、5TB の場合は -R 8 を指定することができます。
以下のコマンドは、リージョンサイズが 2MB のミラー化論理ボリュームを作成します。
# lvcreate -m1 -L 2T -R 2 -n mirror vol_group
ミラーが作成されると、ミラーのリージョンは同期されます。大きなミラーコンポーネントの場合は、同期プロセスに長い時間がかかる可能性があります。Red Hat Enterprise Linux 6.3 では、回復させる必要のない新規のミラーを作成している場合は、
--nosync 引数を指定して、最初のデバイスからの初期の同期が不要であることを示すことができます。
LVM は、単一または複数のミラーと同期するリージョンを追跡するために使用する小さなログを維持します。デフォルトでは、このログはディスク上に保持され、再起動後も永続化するため、マシンが再起動/クラッシュするたびにミラーを再同期する必要はありません。代わりに、
--corelog 引数を使用すると、このログがメモリー上で保持されるように指定できるため、余分なログデバイスが不要になります。しかし、これには再起動のたびにミラー全体を再同期することが必要になります。
以下のコマンドは、ボリュームグループ
bigvg からミラー化論理ボリュームを作成します。論理ボリュームの名前は ondiskmirvol であり、これには単一のミラーがあります。ボリュームのサイズは 12MB で、ミラーログをメモリーに保持します。
# lvcreate -L 12MB -m1 --mirrorlog core -n ondiskmirvol bigvg
Logical volume "ondiskmirvol" created
このミラーログは、いずれかのミラーレッグが作成されるデバイスとは異なるデバイス上で作成されます。しかし、
vgcreate コマンドに --alloc anywhere 引数を使用することにより、ミラーレッグの 1 つと同じデバイス上にミラーログを作成することが可能です。これはパフォーマンスを低下させる可能性がありますが、配下のデバイスが 2 つしかない場合でもミラーを作成できます。
以下のコマンドは、単一のミラーを持つミラー化論理ボリュームを作成します。このミラーログはミラーレッグの 1 つと同じデバイス上にあります。この例では、ボリュームグループ
vg0 は 2 つのデバイスのみで構成されています。このコマンドによって、ボリュームグループ vg0 内に mirrorlv という名前で、サイズが 500 MB のボリュームが作成されます。
# lvcreate -L 500M -m1 -n mirrorlv -alloc anywhere vg0注記
クラスター化されたミラーでは、ミラーログ管理は、その時点でクラスター ID の最も低いクラスターノードによって行われます。そのため、クラスターミラーログを保持するデバイスがクラスターのサブセット上で利用できなくなる場合、最も低い ID を持つクラスターノードがミラーログへのアクセスを保持する限り、クラスター化されたミラーは影響を受けることなく、機能を継続することができます。ミラーは影響を受けないため、自動修正アクション (修復) も実行されません。ただし、最も低い ID のクラスターノードがミラーログにアクセスできなくなると、(他のノードからログへのアクセスが可能かどうかにかかわらず) 自動アクションが作動します。
自動的にミラー化されるミラーログを作成するために、
--mirrorlog mirrored 引数を指定することができます。以下のコマンドはボリュームグループ bigvg からミラー化論理ボリュームを作成します。論理ボリュームは twologvol という名前で、単一のミラーを持ちます。このボリュームのサイズは 12MB で、ミラーログがミラー化され、各ログは別個のデバイス上に保管されます。
# lvcreate -L 12MB -m1 --mirrorlog mirrored -n twologvol bigvg
Logical volume "twologvol" created
標準ミラーログと同様に、
vgcreate コマンドの --alloc anywhere 引数を使用してミラーレッグと同じデバイス上に冗長ミラーログを作成することが可能です。これによってパフォーマンスが低下する可能性がありますが、各ログを別個のデバイス上に保管するための配下のデバイス数がミラーレッグに対して十分でない場合でも、冗長ミラーログの作成が可能となります。
ミラーが作成されると、ミラーのリージョンは同期されます。大きなミラーコンポーネントの場合は、同期プロセスには長い時間がかかる可能性があります。回復させる必要のない新規のミラーを作成している場合は、
--nosync 引数を指定して、最初のデバイスからの初期の同期は不要であることを示すことができます。
ミラーレッグとログ用に使用するデバイス、およびそのデバイスで使用するエクステントを指定することができます。ログを特定のディスクに強制するには、それが配置されるディスク上のエクステントを正確に 1 つ指定します。LVM は、コマンドラインでデバイスが一覧表示される順序を必ずしも優先しません。物理ボリュームが一覧にあれば、それが割り当てが実行される唯一のスペースになります。割り当て済みの物理エクステントが一覧にある場合、そのエクステントは無視されます。
以下のコマンドは、単一のミラーとミラー化されない単一ログを持つミラー化論理ボリュームを作成します。このボリュームは、サイズ 500 MB、名前は
mirrorlv で、ボリュームグループ vg0 から構築されます。第 1 のミラーレッグはデバイス /dev/sda1 上にあり、第 2 のミラーレッグはデバイス /dev/sdb1 上にあり、そのミラーログは /dev/sdc1 上にあります。
# lvcreate -L 500M -m1 -n mirrorlv vg0 /dev/sda1 /dev/sdb1 /dev/sdc1
以下のコマンドは、単一のミラーを持つミラー化論理ボリュームを作成します。このボリュームは、サイズは 500 MB、名前は
mirrorlv であり、ボリュームグループ vg0 から構築されます。第 1 のミラーレッグは、エクステントが 0 から 499 のデバイス /dev/sda1 にあり、第 2 のミラーレッグはエクステントが 0 から 499 のデバイス /dev/sdb1 にあります。ミラーログは、エクステントが 0 のデバイス /dev/sdc1 から始まります。これらは 1MB のエクステントです。指定されたエクステントのいずれかが割り当て済みである場合は、それらは無視されます。
# lvcreate -L 500M -m1 -n mirrorlv vg0 /dev/sda1:0-499 /dev/sdb1:0-499 /dev/sdc1:0注記
Red Hat Enterprise Linux 6.1 リリースでは、単一の論理ボリューム内でストライピングとミラーリングを併用することができます。論理ボリュームの作成と同時にミラーの数 (
--mirrors X) とストライプの数 (--stripes Y) を指定すると、ミラーデバイスの構成デバイスがストライプ化されます。
4.4.3.1. ミラー化論理ボリュームの障害ポリシー
lvm.conf ファイルの activation セクション内の mirror_image_fault_policy と mirror_log_fault_policy のパラメーターを使用すると、デバイスの障害が発生した場合にミラー化論理ボリュームがどのような動作をするかを定義することができます。これらのパラメーターが remove に設定されると、システムは障害のあるデバイスを削除して、そのデバイスなしで実行しようとします。このパラメーターが allocate に設定されていると、システムは障害のあるデバイスを削除して、そのデバイスの代わりとなる新たなデバイス上でのスペースの割り当てを試みます。代わりに割り当てることができる適切なデバイスとスペースがない場合、このポリシーは remove ポリシーと同様に機能します。
デフォルトでは、
mirror_log_fault_policy パラメーターは allocate に設定されています。ログにこのポリシーを使用するとプロセスが速まり、クラッシュやシステムの再起動時にも同期状態を記憶する機能が維持されます。このポリシーを remove に設定すると、ログデバイスに障害が発生した際に、ミラーがメモリー内ログを使用するように切り替わり、ミラーはクラッシュとシステムの再起動時の同期ステータスは記憶せず、ミラー全体が再同期されます。
デフォルトでは、
mirror_image_fault_policy パラメーターは remove に設定されます。このポリシーでは、ミラーイメージに障害が発生すると、良好なコピーが 1 つしか残っていない場合は、ミラーが非ミラー化デバイスに変換されます。ミラーデバイスに対してこのポリシーをallocate に設定すると、ミラーはデバイスを再同期する必要があるため、処理に時間がかかりますが、これによってデバイスのミラー特性を保持することができます。
注記
LVM ミラーにデバイス障害が発生すると、2 段階の回復プロセスが実行されます。第 1 段階では、障害が発生したデバイスの削除が行われます。これによってミラーは、単一のリニアデバイスに縮小されます。第 2 段階では、
mirror_log_fault_policy パラメーターが allocate に設定されている場合、障害の発生したデバイスの置き換えを試みます。ただし、第 2 段階では、他のデバイスが利用可能である場合、ミラーが以前使用していたデバイスの中から、障害とは関係のないデバイスが選択されるという保証はない点に注意してください。
LVM ミラー障害が発生した際の手動で回復する方法ついての情報は、「LVM ミラー障害からの回復」 を参照してください。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.