2.3. LVM 論理ボリューム

LVM では、ボリュームグループは論理ボリュームに分割されます。以下のセクションでは、論理ボリュームのタイプを説明します。

2.3.1. リニアボリューム

リニアボリュームは、複数の物理ボリュームの領域を 1 つの論理ボリュームに統合します。たとえば、60GB ディスクが 2 つある場合は、120GB の論理ボリュームを作成できます。物理ストレージは連結されます。
リニアボリュームを作成すると、論理ボリュームの領域に、物理エクステントの範囲が順番に割り当てられます。たとえば、図2.2「エクステントのマッピング」 にあるように、１ から 99 までの論理エクステントが 1 つ目の物理ボリュームにマッピングされ、 100 から 198 までの論理エクステントが 2 つ目の物理ボリュームにマッピングされます。アプリケーションからは、サイズが 198 エクステントのデバイスが１つあるように見えます。
エクステントのマッピング

図2.2 エクステントのマッピング

論理ボリュームを構成している各物理ボリュームのサイズは、すべて同じである必要はありません。図2.3「サイズの異なる物理ボリュームを用いたリニアボリューム」 は、物理エクステントサイズが 4MB のボリュームグループ VG1 を示しています。このボリュームグループには、PV1 と PV2 という 2 つの物理ボリュームがあります。1 エクステントは 4MB なので、物理ボリュームが分割される単位は 4MB になります。この例では、PV1 のエクステントサイズは 200 (800MB) で、PV2 のエクステントサイズは 100 (400MB) です。リニアボリュームは、エクステントサイズ 1 から 300 (4MB から 1200MB) の間で作成できます。この例では、300 エクステントのリニアボリューム LV1 を作成しました。
サイズの異なる物理ボリュームを用いたリニアボリューム

図2.3 サイズの異なる物理ボリュームを用いたリニアボリューム

物理エクステントのプールから、任意のサイズでリニア論理ボリュームを複数設定することができます。図2.4「複数の論理ボリューム」 は、図2.3「サイズの異なる物理ボリュームを用いたリニアボリューム」 と同じボリュームグループを示していますが、ここでは、そのボリュームグループから論理ボリュームを 2 つ作成しています。250 エクステント (1000MB) の LV1 と、50 エクステント (200MB) の LV2 です。
複数の論理ボリューム

図2.4 複数の論理ボリューム

2.3.2. ストライプ化論理ボリューム

LVM 論理ボリュームにデータを書き込む際に、ファイルシステムは、基礎となる物理ボリューム全体にデータを分配します。このとき、ストライプ化論理ボリュームを作成すると、データを物理ボリュームに書き込む方法を制御することができます。順次読み取りと書き込みが大量に行われる場合には、これによりデータ I/O の効率を向上できます。
ストライピングは、ラウンドロビン式で、指定した数の物理ボリュームにデータを書き込んでいくことで、パフォーマンスを向上させます。I/O は、ストライピングでは並行して実行されます。これにより、ストライプで追加される各物理ボリュームでは、ほぼ直線的なパフォーマンスの向上が期待できます。
以下の図では、3 つの物理ボリュームにデータがストライプ化されている状態を示しています。
  • データの 1 番目のストライプは、1 番目の物理ボリュームに書き込まれます。
  • データの 2 番目のストライプは、2 番目の物理ボリュームに書き込まれます。
  • データの 3 番目のストライプは、3 番目の物理ボリュームに書き込まれます。
  • データの 4 番目のストライプは、1 番目の物理ボリュームに書き込まれます。
ストライプ化された論理ボリュームでは、ストライプのサイズは、エクステントのサイズより小さくなります。
3 つの PV にまたがるデータのストライピング

図2.5 3 つの PV にまたがるデータのストライピング

ストライプ化論理ボリュームは、別のデバイスセットを最初のセットの末端に連結すれば拡張できます。ストライプ化論理ボリュームを拡張するには、ストライプに対応するボリュームグループを構成する、基礎となる物理ボリュームセットに、十分な空き領域が必要です。たとえば、ボリュームグループ全域を使用している 2 方向ストライプがある場合は、そのボリュームグループに物理ボリュームを 1 つだけ追加しても、ストライプは拡張できません。ボリュームグループには物理ボリュームを 2 つ以上追加する必要があります。ストライプ化ボリュームの拡張の詳細は、「ストライプ化ボリュームの拡張」 を参照してください。

2.3.3. RAID 論理ボリューム

LVM は RAID0/1/4/5/6/10 に対応します。LVM の RAID ボリュームには以下の特徴があります。
  • LVM で作成および管理される RAID 論理ボリュームは、MD カーネルドライバーを使用します。
  • RAID1 イメージはアレイから一時的に切り離して、後でアレイにマージし直すことができます。
  • LVM RAID ボリュームはスナップショットに対応します。
RAID 論理ボリュームの作成に関する情報は、「RAID 論理ボリューム」 を参照してください。

注記

RAID 論理ボリュームはクラスターには対応していません。RAID 論理ボリュームは 1 台のマシンに作成でき、かつ排他的にアクティブ化することができますが、複数のマシンで同時にアクティブにすることはできません。排他的ではなく、ミラー化されたボリュームが必要な場合は、「ミラー化ボリュームの作成」 に説明されているように、セグメントタイプの mirror を指定してボリュームを作成する必要があります。

2.3.4. シンプロビジョニングされた論理ボリューム (シンボリューム)

論理ボリュームのシンプロビジョニングが可能になりました。これにより、利用可能なエクステントよりも大きい論理ボリュームを作成できます。シンプロビジョニングを使用すると、空き領域のストレージプール (シンプールと呼ばれる) を管理して、アプリケーションで必要なときに、任意の数のデバイスに割り当てることができます。その後、アプリケーションが実際に論理ボリュームに書き込むときに割り当てるのに使用する、シンプールにバインド可能なデバイスを作成できます。シンプールは、高いストレージ領域をコスト効率よく割り当てるために、動的に拡張できます。

注記

シンボリュームは、クラスターのノード間ではサポートされません。シンプールとそのすべてのシンボリュームは、1 つのクラスターノードでのみ排他的にアクティブ化する必要があります。
ストレージ管理者は、シンプロビジョニングを使用することで物理ストレージをオーバーコミットできるため、多くの場合、追加のストレージを購入する必要がなくなります。たとえば、10 人のユーザーから、各自のアプリケーションに使用するファイルシステムをそれぞれ 100GB 要求された場合、ストレージ管理者は各ユーザーに 100GB と示されるファイルシステムを作成します (ただし、実際には 100GB 未満のストレージが、必要に応じて使用されます) 。シンプロビジョニングを使用する場合、ストレージ管理者がストレージプールを監視し、容量が一杯になり始めたら容量を追加することが重要です。
利用可能な領域をすべて使用できるようにするために、LVM はデータの破棄に対応します。これにより、破棄されたファイルや、その他のブロック範囲で以前に使用された領域を再利用できます。
シンボリュームの作成の詳細は、「シンプロビジョニングされた論理ボリュームの作成」 を参照してください。
シンボリュームは、新たに実装されたコピーオンライト (COW) スナップショット論理ボリュームに対応します。これにより、多くの仮想デバイスでシンプール内の同一データを共有できます。シンプロビジョニングされたスナップショットボリュームの詳細は、「シンプロビジョニングされたスナップショットボリューム」 を参照してください。

2.3.5. スナップショットボリューム

LVM スナップショット機能により、サービスを中断せずに任意の時点でデバイスの仮想イメージを作成できます。スナップショットの取得後に複製元のデバイスに変更が加えられると、データが変更される前に、これから変更される部分のコピーがスナップショット機能により作成されるため、このコピーを使って、デバイスの状態を再構築できます。

注記

LVM は、シンプロビジョニングされたスナップショットに対応します。シンプロビジョニングされたスナップショットボリュームの詳細については、「シンプロビジョニングされたスナップショットボリューム」 を参照してください。

注記

LVM スナップショットは、クラスター内のノード間ではサポートされていません。クラスター化されたボリュームグループ内ではスナップショットボリュームを作成できません。
スナップショットは、スナップショットが作成されてから変更されたデータ部分のみをコピーするため、スナップショット機能に必要なストレージの容量は最小限で済みます。たとえば、複製元の大部分が更新されない場合は、その容量の 3-5 % があればスナップショットを十分に維持することができます。

注記

ファイルシステムのスナップショットコピーは仮想コピーであり、ファイルシステムのメディアバックアップを実際に作成するわけではありません。スナップショットは、バックアップの代替手順にはなりません。
複製元のボリュームへの変更を保管するために確保するスペース量は、スナップショットのサイズによって異なります。たとえば、スナップショットを作成してから複製元を完全に上書きした場合に、その変更を保管するのに必要なスナップショットのサイズは、複製元のボリュームと同じか、それ以上になります。スナップショットのサイズは、予想される変更レベルに応じて決定する必要があります。たとえば、/usr など、その大部分が読み取り用に使用されるボリュームの短期的なスナップショットに必要なスペースは、/home のように大量の書き込みが行われるボリュームの長期的なスナップショットに必要なスペースよりも小さくなります。
スナップショットが満杯になると、そのスナップショットは無効になります。複製元のボリューム上の変更をトラッキングできなくなるためです。スナップショットのサイズは常時監視する必要があります。ただし、スナップショットのサイズは完全に変更することが可能なため、ストレージに余裕があれば、スナップショットが停止しないように、ボリュームサイズを拡大することができます。逆に、スナップショットボリュームサイズが必要以上に大きければ、そのボリュームのサイズを縮小して、他の論理ボリュームで必要となる領域を確保することができます。
スナップショットのファイルシステムを作成すると、複製元への完全な読み取り/書き込みのアクセスがそのまま残ります。スナップショット上のチャンクを変更した場合は、そのチャンクにマークが付けられ、そこには複製元のボリュームのコピーは入りません。
スナップショット機能にはいくつかの用途があります。
  • 最も一般的な用途は、継続的にデータを更新している稼動中のシステムを停止せずに、論理ボリューム上でバックアップを実行する必要がある場合のスナップショット作成です。
  • スナップショットファイルシステムで fsck コマンドを実行し、ファイルシステムの整合性をチェックすれば、複製元のファイルシステムを修復する必要があるかどうかを判断できます。
  • スナップショットは読み取り/書き込み用なので、スナップショットを取ってそのスナップショットに対してテストを実行することにより、実際のデータに触れることなく、実稼働データに対するアプリケーションのテストを実行できます。
  • LVM ボリュームを作成して、Red Hat の仮想化と併用することが可能です。LVM スナップショットを使用して、仮想ゲストイメージのスナップショットを作成できます。このスナップショットは、最小限のストレージを使用して、既存のゲストの変更や新規ゲストの作成を行う上で利便性の高い方法を提供します。Red Hat Virtualization による LVM ベースのストレージプールの作成についての詳細は、『仮想化管理ガイド』 を参照してください。
スナップショットボリュームの作成に関する情報は、「ミラー化ボリュームの作成」 を参照してください。
lvconvert コマンドの --merge オプションを使用して、スナップショットを複製元のボリュームにマージすることが可能です。この機能の用途の 1 つとして挙げられるのはシステムロールバックの実行で、データやファイルを紛失した場合や、システムを以前の状態に復元する必要がある場合に行います。スナップショットボリュームのマージの結果作成される論理ボリュームには、複製元のボリューム名、マイナー番号、UUID が付けられ、マージされたスナップショットは削除されます。このオプションの使用方法は、 「スナップショットボリュームのマージ」 を参照してください。

2.3.6. シンプロビジョニングされたスナップショットボリューム

Red Hat Enterprise Linux は、シンプロビジョニングされたスナップショットボリュームに対応します。シンプロビジョニングされたスナップショットボリュームにより、多くの仮想デバイスを同じデータボリュームに格納することができます。これにより管理が簡略化され、スナップショットボリューム間でのデータ共有が可能になります。
シンボリュームや、LVM スナップショットボリュームの場合、シンプロビジョニングされたスナップショットボリュームは、クラスター内のノード間でサポートされていません。スナップショットボリュームは、1 つのクラスターノードで排他的にアクティブ化する必要があります。
シンプロビジョニングされたスナップショットボリュームの利点は以下のとおりです。
  • 同じボリュームからのスナップショットが複数ある場合に、シンプロビジョニングされたスナップショットボリュームを使えば、ディスクの使用量を減らすことができます。
  • 複製元が同じスナップショットが複数ある場合は、複製元に 1 回書き込むことにより 1 回の COW 操作でデータを保存できます。複製元のスナップショットの数を増やしても、速度が大幅に低下することはありません。
  • シンプロビジョニングされたスナップショットボリュームは、別のスナップショットの作成元の論理ボリュームとして使用できます。これにより、再帰的スナップショット (スナップショットのスナップショットのそのまたスナップショットなど) の深度を任意に決定できます。
  • シン論理ボリュームのスナップショットにより、シン論理ボリュームを作成することもできます。COW 操作が必要になるまで、あるいはスナップショット自体が書き込まれるまで、データ領域は消費されません。
  • シンスナップショットボリュームは、複製元とともにアクティブにしておく必要はありません。そのため、スナップショットボリュームが多数ある場合は、複製元のみをアクティブにし、スナップショットボリュームはアクティブにしないでおくことができます。
  • シンプロビジョニングされたスナップショットボリュームの複製元を削除すると、そのボリュームのスナップショットは、それぞれ独立したシンプロビジョニングボリュームになります。したがって、スナップショットとその複製元のボリュームをマージする代わりに、複製元のボリュームを削除し、その独立したボリュームを新たな複製元ボリュームにして、シンプロビジョニングされたスナップショットを新たに作成できます。
シンスナップショットボリュームを使用する利点は数多くありますが、古い LVM スナップショットボリューム機能の方がニーズに沿うケースもあります。
  • シンプールのチャンクサイズは変更できません。シンプールのチャンクサイズが大きい場合 (1MB など) や、チャンクサイズが短時間のスナップショットには効率的でない場合は、代わりに以前のスナップショット機能を使用できます。
  • シンスナップショットボリュームのサイズを制限することはできません。スナップショットは、必要な場合はシンプール内の全領域を使用するため、ニーズに沿っていない場合があります。
一般的には、使用するスナップショットの形式を決定する際に、使用しているサイトの特定要件を考慮に入れるようにしてください。
シンスナップショットボリュームの設定についての詳細は、「シンプロビジョニングされたスナップショットボリュームの作成」 を参照してください。

2.3.7. キャッシュボリューム

Red Hat Enterprise Linux 7.1 リリースでは、LVM は高速ブロックデバイス (SSD ドライブなど) を、大規模な低速ブロックデバイスのライトバックまたはライトスルーキャッシュとして使用することをサポートします。既存の論理ボリュームのパフォーマンスを改善するためにキャッシュ論理ボリュームを作成したり、大規模で低速なデバイスと共に小規模で高速なデバイスで構成される新規のキャッシュ論理ボリュームを作成したりできます。
LVM キャッシュボリュームの作成については、「LVM 論理ボリュームの作成」 を参照してください。