5.4.3. ミラー化ボリュームの作成
注記
As of the Red Hat Enterprise Linux 6.3 release, LVM supports RAID4/5/6 and a new implementation of mirroring. For information on this new implementation, see 「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 maintains a small log which it uses to keep track of which regions are in sync with the mirror or mirrors. By default, this log is kept on disk, which keeps it persistent across reboots and ensures that the mirror does not need to be resynced every time a machine reboots or crashes. You can specify instead that this log be kept in memory with the
--mirrorlog core argument; this eliminates the need for an extra log device, but it requires that the entire mirror be resynchronized at every reboot.
以下のコマンドは、ボリュームグループ
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) を指定すると、ミラーデバイスの構成デバイスがストライプ化されます。
5.4.3.1. ミラー化論理ボリュームの障害ポリシー リンクのコピーリンクがクリップボードにコピーされました!
リンクのコピーリンクがクリップボードにコピーされました!
lvm.conf ファイルの activation セクション内の mirror_image_fault_policy と mirror_log_fault_policy のパラメーターを使用すると、デバイスの障害が発生した場合にミラー化論理ボリュームがどのような動作をするかを定義することができます。これらのパラメーターが remove に設定されると、システムは障害のあるデバイスを削除して、そのデバイスなしで稼働を試みます。このパラメーター allocate に設定されていると、システムは障害のあるデバイスを削除して、そのデバイスの代わりとなる新たなデバイス上でのスペースの割り当てを試みます。代わりに割り当てることができる適切なデバイスとスペースがない場合、このポリシーは remove ポリシーと同様に機能します。
By default, the
mirror_log_fault_policy parameter is set to allocate. Using this policy for the log is fast and maintains the ability to remember the sync state through crashes and reboots. If you set this policy to remove, when a log device fails the mirror converts to using an in-memory log and the mirror will not remember its sync status across crashes and reboots and the entire mirror will be resynced.
デフォルトでは、
mirror_image_fault_policy パラメーターは remove に設定されています。このポリシーでは、ミラーイメージに障害が発生すると、良好なコピーが1つしか残っていない場合は、ミラーが非ミラー化デバイスに変換されます。ミラーデバイスに対してこのポリシーをallocate に設定すると、ミラーはデバイスを再同期する必要があるため、処理に時間がかかりますが、これによってデバイスのミラー特性を保持することができます。
注記
LVM ミラーにデバイス障害が発生すると、2 段階のリカバリが実行されます。第 1 段階では、障害が発生したデバイスの削除が行われます。これによってミラーは、単一のリニアデバイスに縮小されます。第 2 段階では、
mirror_log_fault_policy パラメーターが allocate に設定されている場合、障害の発生したデバイスの置き換えを試みます。ただし、第 2 段階で、ミラーが以前使用していたデバイスの中で、障害の要因となったデバイスが利用可能な場合には、障害とは関係のないデバイスが選択されるという保証はない点に注意してください。
For information on manually recovering from an LVM mirror failure, see 「LVM ミラー障害からの回復」.