論理ボリューム マネージャー (Linux)

Linuxでは、論理ボリュームマネージャ( LVM ) は、 Linux カーネルに論理ボリューム管理を提供するデバイスマッパーフレームワークです。最近のLinux ディストリビューションのほとんどは LVM に対応しており、ルートファイルシステムを論理ボリューム上に配置することができます。^{[3] [4] [5]}

ハインツ・マウエルシャゲンは、1998年にシスティーナ・ソフトウェアで働いていたときに、 HP-UXのボリュームマネージャから主な設計ガイドラインを採用してオリジナルのLVMコードを書きました。 ^[1]

LVM は次の目的で使用されます。

• 複数の物理ボリュームまたはハードディスク全体から単一の論理ボリュームを作成し( RAID 0に似ていますが、JBODに似ています)、動的なボリュームのサイズ変更を可能にします。
• ホットスワップと組み合わせて、ダウンタイムやサービスの中断なしにディスクを追加および交換できるようにすることで、大規模なハードディスクファームを管理します。
• 小規模なシステム (デスクトップなど) では、インストール時にパーティションに必要なサイズを見積もる必要がなく、LVM を使用すると、必要に応じてファイルシステムのサイズを簡単に変更できます。
• 論理ボリュームのスナップショットを取得して一貫性のあるバックアップを実行します。
• 1 つのパスワードで複数の物理パーティションを暗号化します。

LVM は、ハード ディスクとパーティションの上にある薄いソフトウェア レイヤーと見なすことができ、ハード ドライブの交換、再パーティション化、およびバックアップを管理するための継続性と使いやすさの抽象化を実現します。

• ボリューム グループ (VG) は、新しい物理ボリューム(PV)を吸収するか、既存のボリュームを取り出すことによって、オンラインでサイズを変更できます。
• 論理ボリューム (LV) は、エクステントを連結したり、エクステントを切り捨てたりすることで、オンラインでサイズを変更できます。
• LV は PV 間で移動できます。
• コピーオンライト（CoW）機能を活用した論理ボリューム（LVM1）の読み取り専用スナップショットの作成、 ^[6]または読み取り/書き込みスナップショット（LVM2）
• VG は、分割された LV がまたがっていない限り、その場で分割または結合できます。これは、LV 全体をオフライン ストレージに移行したり、オフライン ストレージから移行したりするときに便利です。
• LVMオブジェクトは管理上の便宜のためにタグ付けすることができる。^[7]
• デーモンの使用により基礎となるデバイスが利用可能になると、VGとLVをアクティブにすることができますlvmetad。^[8]

• ハイブリッドボリュームはdm-cacheターゲットを使用して作成することができ、これにより、フラッシュベースのSSDなどの1つ以上の高速ストレージデバイスを、 1つ以上の低速ハードディスクドライブのキャッシュとして機能させることができます。^[9]
• シンプロビジョニングされたLVはプールから割り当てることができます。^[10]
• デバイスマッパーの新しいバージョンでは、LVMはデバイスマッパーの残りの部分と統合されており、devices/multipath_component_detection=1が設定されている場合にdm-multipathデバイスをサポートする個々のパスを無視しlvm.confます。これにより、LVMがマルチパスデバイスではなく個々のパスでボリュームをアクティブ化するのを防ぎます。^[11]

• LVはRAID 1、5、6などのRAID機能を含むように作成することができます。^[12]
• RAID 0と同様に、LV 全体またはその一部を複数の PV にまたがってストライプ化できます。
• RAID 1バックエンドデバイス（PV）は「書き込み主体」として構成することができ、その結果、必要な場合を除き、そのようなデバイスへの読み取りは回避されます。^[13]
• RAID 機能を含む LV を再構築する際に許容可能な I/O パフォーマンスを維持するためにlvchange --raidmaxrecoveryrate、 とを使用して回復率を制限できます。lvchange --raidminrecoveryrate

LVM は、PV を保持するディスクが複数のホスト コンピューター間で共有される共有ストレージクラスターでも動作しますが、ロック形式を介してメタデータ アクセスを仲介する追加のデーモンが必要になる場合があります。

CLVM

分散ロック マネージャーは、同時LVM メタデータ アクセスを仲介するために使用されます。クラスター ノードが LVM メタデータを変更する必要がある場合は、クラスター内のclvmd他のデーモンと常に通信しclvmd、特定のオブジェクト セットのロックを取得する要求を伝えることができるローカルの から権限を確保する必要があります。

HA-LVM

クラスタ認識は、高可用性機能を提供するアプリケーションに委ねられています。LVM 側では、HA-LVM は CLVM をロック メカニズムとして使用することも、デフォルトのファイル ロックを引き続き使用して、適切なタグを持つ LVM オブジェクトのみへのアクセスを制限することで「衝突」を減らすこともできます。このより単純なソリューションは競合を緩和するのではなく回避するため、同時アクセスは許可されません。そのため、HA-LVM はアクティブ/パッシブ構成でのみ有用であると考えられています。

lvmlockd

2017年現在、分散ロックマネージャに依存せずにLVMオブジェクトのロックをLVMの残りの部分に対して透過的にすることで^[update]置き換えるように設計された安定したLVMコンポーネント。 ^[14] 2016年には大規模な開発が行われました。^[15]clvmd

上記のメカニズムは、LVM のストレージへのアクセスに関する問題のみを解決します。このような LV の上に配置するように選択されたファイル システムは、それ自体でクラスタリングをサポートしている必要があります ( GFS2やVxFSなど)。または、常に単一のクラスタ ノードによってのみマウントされる必要があります (アクティブ/パッシブ構成など)。

LVM VG には、そこから作成される新しいボリュームのデフォルトの割り当てポリシーが含まれている必要があります。これは、lvconvert -Aコマンドを使用して各 LV ごとに変更することも、を使用して VG 自体で変更することもできますvgchange --alloc。断片化を最小限に抑えるために、LVM は最初に最も厳格なポリシー (連続) を試行し、割り当てが最終的に成功するまで、LVM オブジェクトに定義されている最も自由なポリシーに向かって進みます。

RAID 構成では、ほぼすべてのポリシーが各レッグに個別に適用されます。たとえば、LV にclingポリシーがある場合でも、RAID セットアップ内の他のレッグの 1 つですでに使用されている PV は、ファイル システムを拡張しても LVM によって使用されることはありません。RAID 機能を持つ LV は、各レッグを異なる PV に配置するため、他の PV は他のレッグで使用できなくなります。これが唯一の選択肢である場合、LV の拡張は失敗します。この意味で、clingの背後にあるロジックは、アレイの個々のレッグそれぞれを拡張する場合にのみ適用されます。

利用可能な割り当てポリシーは次のとおりです。

• 連続–特定のLV 内のすべてのLE を隣接させて順序付けます。これにより断片化は解消されますが、LV の拡張性は大幅に低下します。
• Cling – LV によってすでに使用されている PV にのみ新しい LE を割り当てるように強制します。これにより、他の LV にもその PV 上のエクステントが存在する可能性が減り、デバイスがダウンした場合に特定の LV の脆弱性が軽減されるだけでなく、断片化が軽減されます。
• 通常– PE をほぼ無差別に選択しますが、並列レッグ (RAID セットアップのレッグなど) が物理デバイスを共有しないようにします。
• どこでも– いかなる制限も課しません。RAID セットアップでは分離要件を無視するため非常に危険であり、RAID の利点のほとんどが損なわれます。リニア ボリュームの場合、断片化が増加する可能性があります。

通常、各物理ボリュームの最初のメガバイトには、「LVM ヘッダー」または「LVM ヘッド」と呼ばれる、主にASCIIでエンコードされた構造が含まれています。元々、LVM ヘッドは冗長性 (部分的なハードウェア障害の場合) のために各 PV の最初と最後のメガバイトに書き込まれていましたが、後に最初のメガバイトのみに変更されました。各 PV のヘッダーは、他のすべての PV と LV の UUID、およびPEからLEへの割り当てマップを含む、ボリューム グループ全体のレイアウトの完全なコピーです。これにより、PV が失われた場合のデータ復旧が簡単になります。

Linux カーネル 2.6 シリーズでは、LVM はデバイス マッパーという形で実装されています。これは、仮想ブロック デバイスを作成し、その内容を他のブロック デバイスにマッピングするためのシンプルなブロック レベルのスキームです。これにより、LVM の実装に必要な、比較的デバッグが難しいカーネル コードの量が最小限に抑えられます。また、I/O リダイレクト サービスを他のボリューム マネージャー ( EVMSなど) と共有することもできます。LVM 固有のコードはすべてユーザー空間ツールにプッシュされ、これらのマッピングを操作し、呼び出されるたびにディスク上のメタデータから状態を再構築するだけです。

ボリューム グループをオンラインにするには、「vgchange」ツールを使用します。

1. 使用可能なすべてのブロック デバイスで PV を検索します。
2. 見つかった各 PV のメタデータ ヘッダーを解析します。
3. 表示されているすべてのボリューム グループのレイアウトを計算します。
4. オンラインにするボリューム グループ内の各論理ボリュームをループし、次の操作を実行します。
   1. オンラインにする論理ボリュームのすべての PV が表示されているかどうかを確認します。
   2. 新しい空のデバイス マッピングを作成します。
   3. それを (「リニア」ターゲットを使用して) 論理ボリュームが属する PV のデータ領域にマップします。

同じボリューム グループ上の PV 間でオンライン論理ボリュームを移動するには、「pvmove」ツールを使用します。

1. 宛先の新しい空のデバイス マッピングを作成します。
2. 「ミラー」ターゲットを元のマップと宛先マップに適用します。カーネルはミラーを「劣化」モードで開始し、元のマップから宛先マップにデータをコピーして同期を開始します。
3. ミラーが同期すると、元のマッピングが宛先に置き換えられ、元のマッピングが破棄されます。

これらのデバイス マッパー操作は透過的に実行されるため、アプリケーションやファイル システムは、基盤となるストレージが移動していることを認識することはありません。

• Linuxカーネル2.6.31までは^[16] 書き込みバリアはサポートされていませんでした（2.6.33で完全にサポートされました）。つまり、 ext3やXFSのようなジャーナルファイルシステムが提供するファイルシステム破損に対する保証は、状況によっては無効になります。^[17]
• 2015年現在^[update]、LVM用のオンラインまたはオフラインのデフラグプログラムは存在しません。この問題は、ボリュームが拡張された場合にのみ断片化が発生し、前述の割り当てポリシーを適用することで、ある程度緩和されます。ただし、断片化は依然として発生するため、断片化を減らすには、コマンドを使用して連続していないエクステントを識別し、手動で再配置する必要がありますpvmove。^[18]
• ほとんどの LVM セットアップでは、各 PV に LVM ヘッドのコピーが 1 つだけ保存されるため、ボリュームがディスク セクタ障害の影響を受けやすくなります。この動作は を使用して上書きできますvgconvert --pvmetadatacopies。LVM が最初のコピーを使用して適切なヘッダーを読み取れない場合は、ボリュームの末尾でバックアップ ヘッダーをチェックします。ほとんどの Linux ディストリビューションは で実行中のバックアップを保持しており/etc/lvm/backup、これにより、 コマンドを使用して破損した LVM ヘッドを手動で書き換えることができますvgcfgrestore。