Red Hat Training

A Red Hat training course is available for RHEL 8

第68章 論理ボリュームの設定および管理

68.1. 論理ボリューム

ボリューム管理により、物理ストレージに抽象化レイヤーが作成され、論理ストレージボリュームを作成できるようになりました。様々な面で、物理ストレージを直接使用するよりも柔軟性が高くなります。また、ハードウェアストレージ設定がソフトウェアから見えなくなるため、アプリケーションを停止したりファイルシステムをアンマウントしたりせずに、サイズ変更や移動が可能になります。したがって、運用コストが削減できます。

物理ストレージを直接使用する場合と比較して、論理ボリュームには、以下のような利点があります。

  • 容量の柔軟性

    論理ボリュームを使用すると、ディスクとパーティションを 1 つの論理ボリュームに集約できるため、ファイルシステムを複数のディスクに拡張できます。

  • サイズ変更可能なストレージプール

    基になるディスクデバイスを再フォーマットしたり、パーティションを再作成したりせずに、簡単なソフトウェアコマンドを使用して論理ボリュームのサイズを拡大または縮小できます。

  • オンラインデータ移動

    より新しく、迅速で、障害耐性の高いストレージサブシステムを導入するために、システムがアクティブな状態でもデータを移動できます。データは、ディスクが使用中の場合でもディスクに再配置できます。たとえば、ホットスワップ可能なディスクを削除する前に空にできます。

  • 便利なデバイスの命名

    論理ストレージボリュームは、ユーザーが命名をカスタマイズしたグループで管理できます。

  • ディスクのストライピング

    2 つ以上のディスクにまたがってデータをストライプ化する論理ボリュームを作成できます。これにより、スループットが大幅に向上します。

  • ボリュームのミラーリング

    論理ボリュームは、データのミラーを設定する際に便利な方法を提供します。

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

    論理ボリュームを使用すると、一貫したバックアップが可能なデバイススナップショットを撮ったり、実際のデータに影響を及ぼすことなく変更の影響をテストしたりできます。

  • シンボリューム

    論理ボリュームは、シンプロビジョニングにできます。これにより、利用可能なエクステントよりも大きな論理ボリュームを作成できます。

  • キャッシュボリューム

    キャッシュ論理ボリュームでは、高速なブロックデバイス (SSD ドライブなど) で構成される小規模な論理ボリュームが使用されるため、頻繁に使用されるブロックを、小規模で高速な論理ボリュームに格納することにより、大規模で低速な論理ボリュームのパフォーマンスが向上します。

68.1.1. LVM アーキテクチャーの概要

LVM 論理ボリュームの基になる物理ストレージユニットは、パーティション、ディスク全体などのブロックデバイスです。このデバイスは、LVM 物理ボリューム (Physical Volume: PV) として初期化されます。

LVM 論理ボリュームを作成する場合は、物理ボリュームをボリュームグループ (Volume Group: VG) に統合します。これによりディスク領域のプールが作成され、そこから LVM 論理ボリューム (Logical Volume: LV) を割り当てます。このプロセスは、ディスクをパーティションに分割する方法に類似しています。論理ボリュームは、ファイルシステムやアプリケーション (データベースなど) に使用されます。

図68.1「LVM 論理ボリュームのコンポーネント」 は、LVM 論理ボリュームのコンポーネントを示しています。

図68.1 LVM 論理ボリュームのコンポーネント

LVM 論理ボリュームのコンポーネント

68.1.2. 物理ボリューム

LVM 論理ボリュームの基になる物理ストレージユニットは、パーティション、ディスク全体などのブロックデバイスです。LVM 論理ボリューム用にデバイスを使用する場合は、デバイスを物理ボリューム (PV) として初期化する必要があります。ブロックデバイスを物理ボリュームとして初期化すると、デバイスの先頭位置にラベルが付けられます。

LVM ラベルは、デフォルトでは 2 番目の 512 バイトセクターに配置されます。物理ボリュームを作成する場合は、先頭の 4 つのセクターのいずれかにラベルを配置することにより、このデフォルト設定を書き換えることができます。これにより、必要に応じて LVM ボリュームを、このセクターを利用する他のユーザーと併用できるようになります。

デバイスがシステムの起動時に任意の順序で初期化されても、LVM ラベルにより物理デバイスの識別とデバイスの順序付けが正しく行われます。LVM ラベルは、再起動してもクラスター全体で維持されます。

LVM ラベルは、デバイスを LVM 物理ボリュームとして識別するものです。これには、物理ボリューム用のランダムな一意識別子 (UUID) が含まれます。また、ブロックデバイスのサイズもバイト単位で保存し、LVM メタデータがデバイスのどこに保存されているかも記録します。

LVM メタデータには、システムにある LVM ボリュームグループの設定詳細が含まれています。デフォルトでは、メタデータの複製コピーが、ボリュームグループ内で、すべての物理ボリュームの、すべてのメタデータ領域に保存されています。LVM メタデータのサイズは小さく、ASCII 形式が使用されます。

現在、LVM では、各物理ボリュームにメタデータのコピーを 1 つまたは 2 つ保存できます。コピーをゼロにすることもできます。デフォルトでは 1 つ保存されます。物理ボリューム上に保存するメタデータのコピー数を一度設定したら、その数を後で変更することはできません。最初のコピーはデバイスの先頭にあるラベルの後に保存されます。2 つ目のコピーがある場合は、デバイスの最後に配置されます。意図したものとは別のディスクに誤って書き込みを行い、ディスクの先頭領域を上書きしてしまった場合でも、デバイス後部にある 2 つ目のコピーでメタデータを復元できます。

68.1.2.1. LVM 物理ボリュームのレイアウト

図68.2「物理ボリュームのレイアウト」 は、LVM 物理ボリュームのレイアウトを示しています。LVM ラベルが 2 番目のセクターにあり、その後にメタデータ領域、使用可能なデバイス領域と続きます。

注記

Linux カーネル (および本書) では、セクターのサイズを 512 バイトとしています。

図68.2 物理ボリュームのレイアウト

LVM 物理ボリュームのレイアウト

68.1.2.2. ディスク上の複数パーティション

LVM の使用により、ディスクパーティションから物理ボリュームを作成できます。Red Hat では、以下のような理由により、ディスク全体に対応するパーティションを 1 つ作成し、1 つの LVM 物理ボリュームとしてラベルを付けることを推奨しています。

  • 管理上の利便性

    各ディスクが一度だけ表示されると、システムのハードウェアの追跡が簡単になります。これは、特にディスクに障害が発生した場合に役に立ちます。さらに、1 つのディスクに物理ボリュームが複数あると、システムの起動時に、不明なパーティションに関するカーネルの警告が発生する可能性があります。

  • ストライピングのパフォーマンス

    LVM は、2 つの物理ボリュームが同じ物理ディスクにあるかどうかを認識しません。2 つの物理ボリュームが同じ物理ディスクにあるときに、ストライプ化された論理ボリュームを作成すると、作成されたボリュームのディスクは同じでも、パーティションは異なる可能性があります。このとき、パフォーマンスは、改善ではなく低下します。

1 つのディスクを、複数の LVM 物理ボリュームに分割しないといけない場合があります (推奨はされません)。たとえば、ディスクがほとんどないシステムで、既存システムを LVM ボリュームに移行する場合に、パーティション間でデータを移動しなければならない場合があります。さらに、大容量のディスクが存在し、管理目的で複数のボリュームグループを必要とする場合は、そのディスクにパーティションを設定する必要があります。ディスクに複数のパーティションがあり、そのパーティションがいずれも同じボリュームグループにある場合に、ストライプ化ボリュームを作成するときは、論理ボリュームに追加するパーティションを注意して指定してください。

68.1.3. ボリュームグループ

物理ボリュームはボリュームグループ (VG) に統合されます。これにより、論理ボリュームに割り当て可能なディスク領域のプールが作成されます。

ボリュームグループ内で、割り当て可能なディスク領域は、エクステントと呼ばれる固定サイズの単位に分割されます。割り当て可能な領域の最小単位は、1 エクステントです。エクステントは、物理ボリュームでは物理エクステントと呼ばれます。

論理ボリュームには、物理エクステントと同じサイズの論理エクステントが割り当てられます。そのため、エクステントのサイズは、ボリュームグループ内のすべての論理ボリュームで同じになります。ボリュームグループは、論理エクステントを物理エクステントにマッピングします。

68.1.4. LVM 論理ボリューム

LVM では、ボリュームグループは論理ボリュームに分割されます。管理者は、標準のディスクパーティションとは異なり、データを破棄せずに論理ボリュームを拡大または縮小できます。ボリュームグループの物理ボリュームが別のドライブまたは RAID アレイにある場合は、ストレージデバイスに論理ボリュームを分散することもできます。

論理ボリュームを、ボリュームに必要なデータよりも小さい容量に縮小すると、データが失われる可能性があります。柔軟性を最大限にするために、現在のニーズに合わせて論理ボリュームを作成し、過剰なストレージ容量を未割り当ての状態にします。必要に応じて、未割り当ての領域を使用するように、論理ボリュームを安全に拡張できます。

重要

AMD システム、Intel システム、ARM システム、および IBM Power Systems サーバーで、ブートローダーは LVM ボリュームを読み取ることができません。/boot パーティション用に、標準的な LVM 以外のディスクパーティションを作成する必要があります。IBM Z では、zipl ブートローダーは、リニアマッピングを使用して LVM 論理ボリュームの /boot に対応します。デフォルトでは、インストールプロセスは常に LVM ボリューム内に / パーティションおよび swap パーティションを作成し、物理ボリュームに別の /boot パーティションを使用します。

以下のセクションでは、論理ボリュームのタイプを説明します。

68.1.4.1. リニアボリューム

リニアボリュームは、複数の物理ボリュームの領域を 1 つの論理ボリュームに統合します。たとえば、60GB ディスクが 2 つある場合は、120GB の論理ボリュームを作成できます。物理ストレージは連結されます。

リニアボリュームを作成すると、論理ボリュームの領域に、物理エクステントの範囲が順番に割り当てられます。たとえば、図68.3「エクステントのマッピング」 で示されているように、1 から 99 までの論理エクステントが 1 つの物理ボリュームにマッピングされ、100 から 198 までの論理エクステントが 2 番目の物理ボリュームにマッピングされます。アプリケーションからは、サイズが 198 エクステントのデバイスが 1 つあるように見えます。

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

リニアボリュームにおけるエクステントのマッピング

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

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

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

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

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

複数の論理ボリューム

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

LVM 論理ボリュームにデータを書き込む際に、ファイルシステムは、基になる物理ボリューム全体にデータを分配します。このとき、ストライプ化論理ボリュームを作成すると、データを物理ボリュームに書き込む方法を制御できます。順次の読み取りおよび書き込みが大量に行われる場合には、これによりデータ I/O の効率を向上できます。

ストライピングは、ラウンドロビン式で、指定した数の物理ボリュームにデータを書き込んでいくことで、パフォーマンスを向上させます。I/O は、ストライピングでは並行して実行されます。これにより、ストライプで追加される各物理ボリュームでは、ほぼ直線的なパフォーマンスの向上が期待できます。

以下は、3 つの物理ボリュームにデータがストライプ化されている状態を示しています。この図は、以下のようになります。

  • データの 1 番目のストライプは、1 番目の物理ボリュームに書き込まれます。
  • データの 2 番目のストライプは、2 番目の物理ボリュームに書き込まれます。
  • データの 3 番目のストライプは、3 番目の物理ボリュームに書き込まれます。
  • データの 4 番目のストライプは、1 番目の物理ボリュームに書き込まれます。

ストライプ化された論理ボリュームでは、ストライプのサイズは、エクステントのサイズを越えることはできません。

図68.6 3 つの物理ボリュームにまたがるデータのストライピング

3 つの物理ボリュームにまたがるデータのストライピング

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

68.1.4.3. RAID 論理ボリューム

LVM は、RAID レベル 0、1、4、5、6、10 に対応します。

LVM RAID ボリュームには以下の特徴があります。

  • LVM が作成および管理した RAID 論理ボリュームは、複数のデバイス (MD) カーネルドライバーを使用します。
  • アレイから RAID1 イメージを一時的に分割し、後でアレイにマージし直すことができます。
  • LVM RAID ボリュームはスナップショットに対応します。

クラスター

RAID 論理ボリュームはクラスターには対応していません。

RAID 論理ボリュームは 1 台のマシンに排他的に作成およびアクティブ化できますが、複数のマシンで同時にアクティブにすることはできません。

Subvolumes

RAID 論理ボリュームを作成するとき、LVM は、データまたはアレイ内のパリティーサブボリュームごとに、サイズが 1 エクステントのメタデータサブボリュームを作成します。

たとえば、2 方向の RAID1 アレイを作成すると、メタデータサブボリュームが 2 つ (lv_rmeta_0 および lv_rmeta_1) と、データサブボリュームが 2 つ (lv_rimage_0 および lv_rimage_1) 作成されます。同様に、3 way ストライプ (および暗黙的なパリティーデバイスが 1 つ) の RAID4 を作成すると、メタデータサブボリュームが 4 つ (lv_rmeta_0lv_rmeta_1lv_rmeta_2、および lv_rmeta_3)、データサブボリュームが 4 つ (lv_rimage_0lv_rimage_1lv_rimage_2、および lv_rimage_3) が作成されます。

インテグリティー

RAID デバイスに障害が発生したり、ソフト破損が発生したときにデータが失われる場合があります。データストレージにおけるソフト破損は、ストレージデバイスから取得したデータが、そのデバイスに書き込まれるデータとは異なることを意味します。RAID LV に整合性を追加すると、ソフト破損の軽減または防止に役立ちます。ソフト破損の詳細と、RAID LV に整合性を追加する方法は、「RAID LV での DM 整合性の使用」 を参照してください。

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

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

注記

クラスターのノード間では、シンボリュームに対応していません。シンプールとそのすべてのシンボリュームは、1 つのクラスターノードで排他的にアクティブにする必要があります。

ストレージ管理者は、シンプロビジョニングを使用することで物理ストレージをオーバーコミットできるため、多くの場合は、追加のストレージを購入する必要がなくなります。たとえば、10 人のユーザーから、各自のアプリケーションに使用するファイルシステムをそれぞれ 100GB 要求された場合、ストレージ管理者は各ユーザーに 100GB のファイルシステムを作成します (ただし、実際には 100GB 未満のストレージが、必要に応じて使用されます)。シンプロビジョニングを使用する場合は、ストレージ管理者がストレージプールを監視し、容量が満杯になり始めたら容量を追加することが重要です。

利用可能な領域をすべて使用できるようにするために、LVM はデータの破棄に対応します。これにより、破棄されたファイルや、その他のブロック範囲で以前に使用された領域を再利用できます。

シンボリュームは、新たに実装されたコピーオンライト (COW) スナップショット論理ボリュームに対応します。これにより、多くの仮想デバイスでシンプール内の同一データを共有できます。

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

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

注記

LVM は、シンプロビジョニングのスナップショットに対応します

スナップショットは、スナップショットの作成後に変更したデータ部分のみをコピーするため、スナップショット機能に必要なストレージは最小限になります。たとえば、コピー元がほとんど更新されない場合は、作成元の 3 ~ 5 % の容量があれば十分にスナップショットを維持できます。

注記

ファイルシステムのスナップショットコピーは仮想コピーであり、ファイルシステムのメディアバックアップを実際に作成するわけではありません。スナップショットは、バックアップの代替手順にはなりません。

作成元のボリュームへの変更を保管するために確保する領域は、スナップショットのサイズによって異なります。たとえば、スナップショットを作成してから作成元を完全に上書きした場合に、その変更を保管するのに必要なスナップショットのサイズは、作成元のボリュームと同じか、それ以上になります。スナップショットのサイズは、予想される変更レベルに応じて決定する必要があります。たとえば、/usr など、その大部分が読み取り用に使用されるボリュームの短期的なスナップショットに必要な領域は、/home のように大量の書き込みが行われるボリュームの長期的なスナップショットに必要な領域よりも小さくなります。

スナップショットが満杯になると、作成元のボリュームの変更を追跡できなくなるため、そのスナップショットは無効になります。スナップショットのサイズは定期的に監視する必要があります。ただし、スナップショットのサイズは完全に変更することが可能なため、ストレージに余裕があれば、スナップショットが停止しないように、スナップショットのボリュームサイズを拡大できます。逆に、スナップショットのボリュームサイズが必要以上に大きければ、そのボリュームのサイズを縮小して、他の論理ボリュームで必要となる領域を確保できます。

スナップショットのファイルシステムを作成しても、作成元への完全な読み取り/書き込みのアクセスは引き続き可能です。スナップショット上のチャンクを変更した場合は、そのチャンクにマークが付けられ、そこには、作成元のボリュームのコピーは入りません。

スナップショット機能にはいくつかの用途があります。

  • 最も一般的な用途は、継続的にデータを更新している稼動中のシステムを停止せずに、論理ボリューム上でバックアップを実行する必要がある場合にスナップショットを撮ることです。
  • スナップショットのファイルシステムで fsck コマンドを実行してファイルシステムの整合性を確認し、作成元のファイルシステムを修復する必要があるかどうかを判断できます。
  • スナップショットは読み取りおよび書き込み用であるため、スナップショットを撮ってそのスナップショットにテストを実行することにより、実際のデータに触れることなく、実稼働データにアプリケーションのテストを実行できます。
  • LVM ボリュームを作成して、Red Hat の仮想化と併用することが可能です。LVM スナップショットを使用して、仮想ゲストイメージのスナップショットを作成できます。このスナップショットは、最小限のストレージを使用して、既存のゲストの変更や新規ゲストの作成を行う上で利便性の高い方法を提供します。

lvconvert コマンドの --merge オプションを使用して、スナップショットを作成元のボリュームにマージできます。この機能の用途の 1 つがシステムロールバックの実行で、データやファイルを紛失した場合や、システムを以前の状態に復元する必要がある場合に行います。スナップショットボリュームのマージ後の論理ボリュームには、作成元のボリューム名、マイナー番号、UUID が付けられ、マージされたスナップショットは削除されます。

68.1.4.6. シンプロビジョニングのスナップショットボリューム

Red Hat Enterprise Linux は、シンプロビジョニングのスナップショットボリュームのサポートを提供します。シンプロビジョニングのスナップショットボリュームにより、多くの仮想デバイスを同じデータボリュームに格納できます。これにより管理が簡略化され、スナップショットボリューム間でのデータ共有が可能になります。

シンボリュームや、LVM スナップショットボリュームの場合、シンプロビジョニングのスナップショットボリュームは、クラスターのノード間では対応していません。スナップショットボリュームは、1 つのクラスターノードで排他的にアクティブにする必要があります。

シンプロビジョニングのスナップショットボリュームの利点は以下のとおりです。

  • 同じボリュームからのスナップショットが複数ある場合に、シンプロビジョニングのスナップショットボリュームを使用すれば、ディスクの使用量を減らすことができます。
  • 作成元が同じスナップショットが複数ある場合は、作成元に 1 回書き込むことにより、1 回の COW 操作でデータを保存できます。作成元のスナップショットの数を増やしても、速度が大幅に低下することはありません。
  • シンプロビジョニングのスナップショットボリュームは、別のスナップショットの作成元の論理ボリュームとして使用できます。これにより、再帰的スナップショット (スナップショットのスナップショットのそのまたスナップショットなど...)
  • シン論理ボリュームのスナップショットにより、シン論理ボリュームを作成することもできます。COW 操作が必要になるまで、あるいはスナップショット自体が書き込まれるまで、データ領域は消費されません。
  • シンプロビジョニングのスナップショットボリュームは、作成元とともにアクティブにしておく必要はありません。そのため、スナップショットボリュームが多数ある場合は、作成元のみをアクティブにし、スナップショットボリュームはアクティブにしないでおくことができます。
  • シンプロビジョニングのスナップショットボリュームの作成元を削除すると、そのボリュームのスナップショットは、それぞれ独立したシンプロビジョニングボリュームになります。したがって、スナップショットとその作成元のボリュームをマージする代わりに、作成元のボリュームを削除し、その独立したボリュームを新たな作成元ボリュームにして、シンプロビジョニングのスナップショットを新たに作成できます。

シンプロビジョニングのスナップショットボリュームを使用する利点は数多くありますが、古い LVM スナップショットボリューム機能の方がニーズに適している場合もあります。

  • シンプールのチャンクサイズは変更できません。シンプールのチャンクサイズが大きい場合 (1MB など) や、そのチャンクのサイズでは効率的ではない短期間のスナップショットが必要な場合は、代わりに以前のスナップショット機能を使用できます。
  • シンプロビジョニングのスナップショットボリュームのサイズを制限することはできません。スナップショットは、必要な場合はシンプール内の全領域を使用します。これは、ニーズに適さない場合があります。

一般的には、使用するスナップショットの形式を決定する際に、使用しているサイトの特定要件を考慮するようにしてください。

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

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