Ubuntuの論理ボリュームマネージャ概説

 ハードディスクはアクセス速度が遅く、故障も多い。さすがにワーキングメモリとして使われることはなくなったが、固定サイズのハードディスク・パーティションは今なおストレージ領域の主流である。そのため、速度やデータ損失の問題だけでなく、サーバをインストールする際のパーティションサイズの計算が正しいか、また(ほとんど未使用のパーティションがほかにあるのに)特定のパーティションだけが空き領域不足に陥っていないかにも気を配る必要がある。さらに、実稼働中のシステムで物理ボリュームの境界を越えるパーティションの移動が必要になったりするとかなり厄介だ。

本稿は、最近出版された書籍The Offical Ubuntu Book, Third Edition(Prentice Hall、2008年6月刊、Copyright 2008 Canonical, Ltd.)からの抜粋。

 RAIDは確かに役に立つ。パフォーマンスや耐故障性(フォールトトレランス)の問題に対してはすばらしい効果を発揮するが、あまりに下位のレベルで動作するのでパーティションのサイズや移動の柔軟性という面では役に立たない。我々が本当に求めているのは、パーティションの概念の抽象レベルを1つ引き上げる、つまり、根底にある物理媒体がパーティションの影響を受けずに済むようにする手段だ。その結果、パーティションサイズの容易な変更や、複数の物理ドライブで構成されるパーティションの作成が可能になる。また、あるパーティションから削った領域を簡単に別のパーティションに加えたり、稼働中のサーバに載っている物理ドライブ上でパーティションの設定を変更できたりするのだ。

 論理ボリューム管理(LVM:Logical Volume Management)のすばらしさは、ストレージの基本単位を物理的なドライブから仮想(論理)的なドライブに換えてくれる仕組みにある。企業向けの高価なUNIXオペレーティングシステムの機能だったLVMは、以前はサードパーティのベンダから購入するしかなかった。やがてフリーソフトウェアの影響力が増大するなか、1998年にHeinz Mauelshagen氏によってLinux向けの論理ボリュームマネージャが実装された。我々がLVMと呼んでいるのはこれだ。それ以来、LVMは幾多の改良を重ね、今では実稼働環境で広く利用されている。Ubuntuインストーラでは、サーバに対するLVMの設定がインストール中に簡単に行えるようになっている。

LVMのしくみと用語

 LVMは、しくみを理解するのがRAIDよりもいささか難しい。ストレージの扱い方が全体的に見直されており、新たな専門用語を覚える必要があるからだ。LVMでは、物理ボリューム(PV:Physical Volume)によってディスク領域が提供されるものとし、(OSにおけるマウントポイントへのパーティションの対応付けのような)特有の機構はない。PVをグループ化して得られるボリュームグループ(VG:Volume Group)は、古き良き時代の規格化されたハードディスクドライブに似た仮想的なストレージプールとなる。これらのVGを切り分けて作成されるのが論理ボリューム(LV:Logical Volume)であり、LVMでは、このLVが我々の扱い慣れた通常のパーティションに相当する。ファイルシステムをこれらのLV上に作成し、マウントすることでディレクトリツリーが形成される。内部では、LVMによって物理ボリュームが小さなブロック単位(デフォルトでは4MB)に分割されており、それぞれのブロックを物理エクステント(PE:Physical Extent)と呼ぶ。

 LVMを利用するには、まずハードディスクドライブ上に1つ以上のパーティションを設定する。これらのパーティションが物理ボリューム(PV)となり、各PVは物理エクステント(PE)単位に分割される。続いてPEをグループ化することでボリュームグループ(VG)を作成し、最後にVG上で論理ボリューム(LV)の作成を行う。ハードディスクドライブの物理的なパーティションではなく、仮想的なパーティションであるこうしたLVがファイルシステムを形成し、OSへのマッピングとマウントの対象となる。結局は従来と同じ固定サイズのパーティションになるのに、こんな複雑なしくみに変えて何の利点があるのかと思われるかもしれない。続きを読めば、その利点がすぐにわかるだろう。

 LVMの物理ボリュームが物理エクステントという等サイズのブロックに分割されているのは、そうすることでボリュームグループ(論理ボリュームに切り分けられる領域)の定義が、従来のパーティションのような「物理ドライブ上の物理的領域」から「物理エクステントの集まり」へと変わるからだ。ここでは「エクステントの集まり」といっているだけで、それらの物理的な場所については何も言及しておらず、ボリュームグループのサイズに関する制限もない。さまざまなドライブの物理エクステント(PE)を寄せ集めて1つのボリュームグループ(VG)にできるので、パーティションの概念を抽象化し、物理的なドライブの制約を取り除くことが可能になる。いったん作成したVGは、(別のVGからのエクステントの移動、または新たに追加した物理ボリュームのエクステントの利用によって)エクステントを追加するだけでサイズを増やせる。また、移動先の物理エクステントに対してデータの再配置を行うだけで、別の物理ストレージへの移し替えができる。何よりすばらしいのは、こうした操作がサーバを停止させずにその場で可能なことだ。

LVMの設定

 意外なことに、(Ubuntuの)インストール時におけるLVMの設定はRAIDほど難しくない。LVMで使用する物理ドライブごとにパーティションの作成を行う点はRAIDの場合と同じだが、それらをLVM用の物理領域として指定する必要がある。ここでは、物理ボリューム(PV)が実際の物理的なハードディスクドライブではなく、作成したパーティションにあたることに注意してほしい。

 ドライブ全体をLVMのパーティションに割り当てる必要はない。LVMで使用するストレージパーティションと、ファイルシステムが配置された本来のパーティションを共存させてもよい。ただし、先に進む前にパーティションの設定に問題がないか確認すること。インストーラがLVMの設定に入ると、LVM用のパーティションを含むすべてのドライブでパーティションレイアウトの変更ができなくなる。

 以下では、4つのハードディスクドライブ(それぞれの容量は10、20、80、120GB)を持つサーバでの設定を想定する。各ドライブで利用可能なすべての領域を使ってLVM用パーティション、つまり物理ボリューム(PV)を作成したうえで、最初の2つのPVで30GBのボリュームグループ(VG)を、残り2つのPVで200GBのVGを作成するとしよう。各VGは仮想的なハードディスクドライブとして機能し、どちらにも通常のパーティションを作成するのと同じように論理ボリュームを作成できる。

 RAIDの場合と同様、ドライブの名前を選択した状態でEnterキーを押すと、そのパーティションテーブルを消去できる。さらに「FREE SPACE」という項目を選択してEnterキーを押すと、物理ボリューム(LVM用の物理領域として使われるように設定されたパーティション)を作成できる。残り3つのLVM用パーティションも準備できたら、パーティショニングのメニューにある「Configure the Logical Volume Manager」(論理ボリュームマネージャの設定)を選択する。

 すると、パーティションレイアウトに関する警告メッセージに続いて、ボリュームグループ(VG)と論理ボリューム(LV)の変更が行える簡素なLVM用ダイアログが現れる。ここでは、前者(VGの変更)を選択し、前述の想定に従って適切な物理ボリューム(PV)を組み合わせて必要な2つのVGを作成する。続いて「Modify Logical Volumes」(論理ボリュームの変更)を選択し、システムで必要になる標準的なパーティション群(「/」、「/var」、「/home」、「/tmp」など)に対応するLVを作成する。

 LVMがパーティション設定の柔軟性向上につながることは、既におわかりいただけただろうか。たとえば「/var」に25GBを割り当てたければ、最初に作成したボリュームグループ(VG)から論理ボリュームを切り出せばよい。そうすれば、容量の小さいほうの2つのハードディスクドライブが「/var」に割り振られる。また、あとで「/var」の領域が大きすぎるとわかった場合には、最初のVGのストレージ領域の一部を2番目のVGに移すことができる。こうした柔軟性は数え上げればきりがない。

 しかし、LVMによって冗長性は実現できない。LVMのねらいは、耐故障性ではなく柔軟性をストレージに与えることだからだ。先ほどの例では、「/var」ファイルシステムの論理ボリュームが存在するボリュームグループが、2つのハードディスクドライブで構成されている。そのため、どちらか一方のドライブが故障しただけでこのファイルシステム全体が破壊されてしまうが、そもそもLVMにはこうした問題を回避できる機能がない。

 耐故障性を求めるなら、RAIDを構成する物理ボリュームでボリュームグループを構築すればよい。先ほどの例であれば、まず容量が10GBのハードディスクドライブ全体で1つのパーティションを作り、そこにRAIDボリューム用の物理領域を割り当てる。次に、20GBのハードディスクにも10GBのパーティションを2つ作り、そのうち1つをRAID用の物理領域にする。続いて、RAIDの設定に入り、両ドライブのそれぞれの10GBのRAIDパーティションでRAID1アレイを構成する。ただし、このRAIDアレイには普通のファイルシステムを割り当てるのではなく、LVMの物理領域として使うための指定を行う。LVMの設定になると、このRAIDアレイがその他の物理ボリュームと同じように表示されるが、実際には冗長化された物理ボリュームになっている。RAIDアレイを構成する物理ドライブが1台故障しても、LVMには影響がなく、データの損失も一切発生しない。当然、標準的なRAIDアレイにも限界はある。故障したハードディスクの数が許容範囲を超え、アレイのシャットダウンに至ると、LVMは正常に動作できなくなる。

 インストール時におけるRAIDアレイおよびLVMの設定が済んだら、今度はサーバインストール後のこうしたアレイの管理方法について学ぶ必要があるだろう。これについては、Linux Documentation Projectによるそれぞれの解説ドキュメント(http://www.tldp.org/HOWTO/Software-RAID-HOWTO.htmlおよびhttp://www.tldp.org/HOWTO/LVM-HOWTO)の一読をお勧めする。専門的なところもあるが、ここで説明した内容を把握していれば、かなり細部まで理解できるはずだ。

Linux.com 原文(2008年7月30日)