コンピュータストレージにおいて、論理ボリューム管理(LVM )は、従来のパーティション分割方式よりも柔軟な方法で大容量ストレージデバイス上の領域を割り当てる方法を提供します。具体的には、ボリュームマネージャは、パーティション(または一般的にはブロックデバイス)を連結、ストライピング、またはその他の方法で結合して、より大きな仮想パーティションを作成できます。管理者は、システムの使用を中断することなく、これらの仮想パーティションのサイズ変更や移動を行うことができます。
ボリューム管理は、ストレージ仮想化の多くの形態のうちの1つにすぎません。その実装は、オペレーティングシステム(OS)のデバイスドライバスタック内のレイヤーで行われます(ストレージデバイス内やネットワーク内ではありません)。

ほとんどのボリュームマネージャの実装は、基本的な設計を共有しています。それらは、ハードディスク、ハードディスクパーティション、または外部ストレージデバイスの論理ユニット番号(LUN)のいずれかである物理ボリューム(PV)から始まります。ボリューム管理では、各PVは物理エクステント(PE)と呼ばれる一連のチャンクで構成されているとみなされます。HP-UXやLinuxなどのボリュームマネージャでは、PEのサイズが均一ですが、 Veritasなどのボリュームマネージャでは、PEのサイズが可変で、自由に分割および結合できます。
通常、PE(物理要素)は論理エクステント(LE)に1対1でマッピングされます。ミラーリングでは、1つのLEに複数のPEがマッピングされます。これらのPEは、物理ボリュームグループ(PVG)から取得されます。PVGは、 RAID 1アレイのハードディスクと同様の働きをする、同じサイズのPVのセットです。PVGは通常、冗長性を最大限に高めるために、異なるディスクまたはデータバス上に配置されます。
システムはLE(論理要素)をボリュームグループ(VG)にプールします。プールされたLEは、論理ボリューム(LV)と呼ばれる仮想ディスクパーティションに連結できます。システムは、ディスクパーティションと同様に、 LVを生のブロックデバイスとして使用できます。つまり、LV上にマウント可能なファイルシステムを作成したり、スワップストレージとして使用したりできます。
ストライプLVは、連続する各LEを異なるPVから割り当てます。LEのサイズによっては、複数のPVの読み取りスループットを組み合わせることで、大規模なシーケンシャルリードのパフォーマンスを向上させることができます。
管理者は、論理ボリューム (LV) を拡張 (LE を連結) したり、縮小 (LE をプールに戻す) したりできます。連結する LE は連続している必要はありません。これにより、既に割り当てられている LE を移動することなく LV を拡張できます。ボリュームマネージャによっては、オンライン中に LV のサイズをどちらの方向にも変更できます。LV のサイズを変更しても、その上のファイルシステムのサイズが必ずしも変更されるわけではなく、単に格納領域のサイズが変更されるだけです。オンラインでサイズ変更可能なファイルシステムは、アプリケーションを中断することなくシステムがストレージをリアルタイムで調整できるため推奨されます。
PVとLVは、異なるVG間で共有したり、異なるVGにまたがって使用したりすることはできません(ただし、一部のボリュームマネージャでは、同じホスト上のVG間で自由に移動できる場合があります)。これにより、管理者はVGを単一の管理単位として、簡単にオンラインにしたり、オフラインにしたり、ホストシステム間で移動したりすることができます。
VGは、新しいPVを取り込むことでストレージプールを拡張したり、PVから撤退することで縮小したりできます。これには、既に割り当て済みのLEをPVから移動することが含まれる場合があります。ほとんどのボリュームマネージャは、この移動をオンラインで実行できます。基盤となるハードウェアがホットプラグ対応であれば、エンジニアはシステムを停止することなくストレージをアップグレードまたは交換できます。
ハイブリッドボリュームとは、意図的に、かつ不透明な形で2つの別々の物理ボリュームを使用するボリュームのことです。例えば、ワークロードがランダムシークで構成されている場合、頻繁に使用されるデータや最近書き込まれたデータを永続的に保存するためにSSDを使用し、使用頻度の低いデータを長期保存するために大容量の回転式磁気メディアを使用するといったことが可能です。Linuxでは、この目的のためにbcacheまたはdm-cacheを使用できます。OS Xでは、 Fusion Driveを使用できます。ZFSもファイルシステムレベルでこの機能を実装しており、管理者がマルチレベルの読み書きキャッシュを構成できるようになっています。
ハイブリッドボリュームは、ソリッドステートストレージと回転磁気メディアを組み合わせたハイブリッドドライブと同様の概念に基づいています。
ボリュームマネージャの中には、各LEにコピーオンライトを適用することでスナップショットを実装するものもあります。この方式では、ボリュームマネージャはLEへの書き込み直前に、コピーオンライトテーブルにLEをコピーします。これにより、LVの古いバージョンであるスナップショットが保持され、後でコピーオンライトテーブルを現在のLVに重ね合わせることで再構築できます。ボリューム管理がシンプロビジョニングと破棄の両方をサポートしていない限り、元のボリューム内のLEに書き込みが行われると、スナップショットボリュームに永続的に保存されます。スナップショットボリュームが元のボリュームよりも小さく作成されている場合(これは一般的な方法です)、スナップショットが動作しなくなる可能性があります。
スナップショットは、ビジー状態のデータベースからテーブルファイルなどの揮発性データの自己整合性のあるバージョンをバックアップしたり、大規模な変更(オペレーティングシステムのアップグレードなど)を単一の操作でロールバックしたりするのに役立ちます。スナップショットは、ストレージを静止状態にするのと同様の効果があり、 Microsoft Windows のシャドウコピー(VSS) サービスに似ています。
LinuxベースのライブCDの中には、スナップショットを使用して読み取り専用の光ディスクへの読み書きアクセスをシミュレートするものもあります。
論理ボリュームは、基盤となるストレージデバイスがPE(パフォーマンス要素)を連続的に割り当てていない場合、外部断片化の影響を受ける可能性があります。これにより、磁気ディスクやその他の回転メディアなど、シーク速度の遅いメディアでのI/Oパフォーマンスが低下する可能性があります。しかし、固定サイズのPEを使用するボリュームマネージャは、通常、これらのシークのコストを償却するために、 PEを比較的大きく設定します(たとえば、 Linux LVMはデフォルトで4MBを使用します)。
Core StorageやLinux LVMのようにボリューム管理のみを行う実装では、ボリューム管理をファイルシステムから分離して抽象化すると、特定のファイルやディレクトリのストレージに関する意思決定を容易に行う能力が失われます。たとえば、特定のディレクトリ(ファイルシステム全体ではなく)をより高速なストレージに永続的に移動する場合、ファイルシステムのレイアウトと基盤となるボリューム管理レイヤーの両方をたどる必要があります。たとえば、Linuxでは、ファイルシステム内のファイルの内容のオフセットを手動で特定し、次にpvmove(そのファイルとは関係のないデータとともに)エクステントを高速なストレージに手動で移動する必要があります。ボリューム管理とファイル管理を別々のサブシステムとして実装するのではなく、同じサブシステム内で実装することで、理論的には全体のプロセスが簡素化されます。
{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク){{cite web}}: CS1 maint: 数値名: 著者リスト (リンク){{cite web}}: CS1 maint: 数値名: 著者リスト (リンク){{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)