Product SiteDocumentation Site

第12章 高度な管理

12.1. RAID と LVM
12.1.1. ソフトウェア RAID
12.1.2. LVM
12.1.3. RAID それとも LVM?
12.2. 仮想化
12.2.1. Xen
12.2.2. LXC
12.2.3. KVM を使った仮想化
12.3. 自動インストール
12.3.1. Fully Automatic Installer (FAI)
12.3.2. Debian-Installer の preseed
12.3.3. Simple-CDD: 一体型の解決策
12.4. 監視
12.4.1. Munin のセットアップ
12.4.2. Nagios のセットアップ
この章では、我々が既に説明した一部の側面を異なる視点から再度取り上げます: 1 台のコンピュータにインストールするのではなく、大規模な配備システムについて学びます; インストール時に RAID や LVM ボリュームを作成する代わりに、我々は手作業でそれを行う方法について学びます。こうすることで最初の選択を訂正する事が可能です。最後に、我々は監視ツールと仮想化技術について議論します。その結果として、この章はより熟練した管理者を対象にしており、ホームネットワークに責任を負う個人を対象にしていません。

12.1. RAID と LVM

4章インストールでは、インストーラの視点からこれらの技術を説明し、最初からこれらを簡単に配備するための統合方法について説明しました。最初のインストールの後、管理者は再インストールという手間のかかる最終手段を行使する事無く、より大きなストレージ領域の要求に対処しなければいけません。管理者は RAID と LVM ボリュームを操作するために必要なツールを理解しなければいけません。
RAID と LVM は両方ともマウントされたボリュームを物理的に対応する物 (実際のハードディスクドライブまたはそのパーティション) から抽象化する技術です; RAID は冗長性を導入することでデータをハードディスク障害から守り、LVM はボリューム管理をより柔軟にしてディスクの実サイズに依存しないようにします。どちらの場合であっても、最終的にシステムには新しいブロックデバイスが追加されますが、そのブロックデバイスをある物理ディスクに対応付けなくとも、ファイルシステムやスワップ領域を作成するために使う事が可能です。RAID と LVM は全く異なる生い立ちを持っていますが、両者の機能は多少重複しています。このため、両者は一緒に言及される事が多いです。
RAID と LVM のどちらの場合も、カーネルはハードディスクドライブやパーティションに対応するものとよく似たブロックデバイスファイルを提供します。アプリケーションやカーネルの別の部分がそのようなデバイスのあるブロックにアクセスを要求する場合、適切なサブシステムがブロックを対応する物理層に転送します。設定に依存して、このブロックは 1 つか復数の物理ディスクに保存されます。その物理的場所は論理デバイス内のブロックの位置と直接的に対応するものではないかもしれません。

12.1.1. ソフトウェア RAID

RAID Redundant Array of Independent Disks を意味します。このシステムの目標はハードディスク障害の際にデータ損失を防ぐ事です。一般的な原則は極めて単純です: データは設定可能な冗長性のレベルに基いて 1 つではなく復数のディスクに保存されます。冗長性の量に依存して、たとえ予想外のディスク障害が起きた場合でも、データを残りのディスクから損失なく再構成する事が可能です。
RAID は専用ハードウェア (SCSI や SATA コントローラカードに統合された RAID モジュール) またはソフトウェア抽象化 (カーネル) を使って実装する事が可能です。ハードウェアかソフトウェアかに関わらず、十分な冗長性を備えた RAID システムはディスク障害があっても透過的に利用可能な状態を継続する事が可能です; スタックの上層 (アプリケーション) はディスク障害にも関わらず、引き続きデータにアクセス可能です。もちろん「信頼性低下状態」は性能に影響を与え、冗長性を低下させます。このため、もう一つ別のディスク障害が起きるとデータを失うことになります。それ故、具体的に言えば管理者は障害の起きたディスクを交換して、せめて信頼性低下状態よりも状態を悪くしないように努力します。新しいディスクが配備されると、RAID システムは要求されたデータを再構成する事が可能です。こうすることで信頼性の高い状態に戻ります。アプリケーションは、RAID アレイが信頼性低下状態か再構成状態の間にアクセス速度が低下する可能性のある点を除いて、何も気付かないでしょう。
RAID がハードウェアで実装された場合、その設定は通常 BIOS セットアップツールによってなされます。カーネルは RAID アレイを、デバイス名は違うかもしれませんが標準的な物理ディスクとして機能する、単一のディスクとみなします。例えば、Squeeze のカーネルは一部のハードウェア RAID アレイを /dev/cciss/c0d0 として利用可能にします; Wheezy のカーネルはこの名前をより自然な /dev/sda に変えましたが、RAID コントローラによっては命名規則が異なるかもしれません。
この本ではソフトウェア RAID だけに注目します。

12.1.1.1. 様々な RAID レベル

実際のところ RAID は 1 種類しかないわけではなく、そのレベルによって識別される復数の種類があります; 設計と提供される冗長性の度合いが異なる復数の RAID レベルが存在します。より冗長性を高くすれば、より障害に強くなります。なぜなら、より多くのディスクで障害が起きても、システムを動かし続ける事ができるからです。これに応じて、与えられた一連のディスクに対して利用可能な領域が小さくなります; つまり、あるサイズのデータを保存するために必要なディスク領域のサイズが多くなります。
リニア RAID
カーネルの RAID サブシステムを使うことで、「リニア RAID」を作る事も可能ですが、これは適切な RAID ではありません。なぜなら、このリニア RAID には冗長性が一切無いからです。カーネルはただ単純に復数のディスク端と端をを統合し結果的に統合されたボリュームを仮想ディスク (1 つのブロックデバイス) として提供します。これがリニア RAID のすべてです。リニア RAID を使うのは極稀な場合に限られます (後から使用例を説明します)。特に、冗長性が無いということは 1 つのディスクの障害が統合されたボリューム全体を駄目にする、そしてすべてのデータを駄目にする事を意味します。
RAID-0
RAID-0 レベルも冗長性を提供しませんが、順序通り単純に物理ディスクを連結する構成ではありません: 物理ディスクはストライプ状に分割され、仮想デバイスのブロックは互い違いになった物理ディスクのストライプに保存されます。例えば 2 台構成の RAID-0 セットアップでは、偶数を付番されたブロックは最初の物理ディスクに保存され、奇数を付番されたブロックは 2 番目の物理ディスクに保存されます。
RAID-0 システムは信頼性を向上させることではなく、性能を向上させる事を目標にしています。システムの信頼性、データの可用性は (リニア RAID と同様に) ディスク障害があればすぐに脅かされるからです: 隣接した巨大なデータにシーケンシャルアクセスする場合、カーネルは両方のディスクから平行して読み込む (書き込む) 事が可能でしょう。この事により、データの転送率が増加します。しかしながら、RAID-0 が使われる機会は減り、代わりに LVM (後から説明します) が使われるようになっています。
RAID-1
RAID-1 レベルは「RAID ミラーリング」としても知られ、最も簡単で最も広く使われています。RAID-1 の標準的な構造では、同じサイズの 2 台の物理ディスクを使い、物理ディスクと同じサイズの論理ボリュームが利用可能になります。データを両方のディスクに保存するため、「ミラー」と呼ばれています。一方のディスクに障害があれば、他方のディスク上のデータを利用する事が可能です。非常に重要なデータ用に、もちろん RAID-1 を 2 台以上の構成にする事も可能ですが、これはハードウェア費用と利用可能な保存領域の比率に直接的な影響を与えます。
RAID-1 レベルは、高価であるにも関わらず (物理ストレージ領域の、良くても、たった半分しか使えない)、広く実運用されています。RAID-1 は簡単に理解でき、簡単にバックアップ可能です: 両方のディスクが全く同じ内容を持っているため、運用システムに影響を与えることなしに、片方を一時的に取り外す事が可能です。通常、読み込み性能は上昇します。なぜなら、カーネルはデータの半分をそれぞれのディスクから平行して読む事ができるからです。これに対して、書き込み性能はそれほど悪化しません。N 台のディスクからなる RAID-1 アレイの場合、データは N-1 台のディスク障害に対して保護されます。
RAID-4
RAID-4 は広く使われていません。RAID-4 は実データを保存するために N 台のディスクを使い、冗長性情報を保存するために 1 台の追加的ディスクを使います。追加的ディスクに障害が起きた場合、システムは他の N 台からデータを再構成する事が可能です。N 台のデータディスクの内最大で 1 台に障害が起きた場合、残りの N-1 台と「パリティ」ディスクには、要求されたデータを再構成するために十分な情報が含まれます。
RAID-4 は高価過ぎるわけではありません。なぜなら、1 台当たりの費用は N 分の 1 だけ増加するに過ぎないからです。また、読み込み性能には大きな影響がありませんが、書き込み性能は悪化します。加えて、N 台の実データ用ディスクに対して書き込むと、パリティディスクに対する書き込みが発生するので、パリティディスクは実データ用ディスクに比べて書き込み回数が増えます。その結果、パリティディスクは極めて寿命が短くなります。RAID-4 アレイのデータは (N+1 台のディスクの内) 1 台の障害に対して保護されます。
RAID-5
RAID-5 は RAID-4 の非対称性問題を対処したものです。パリティブロックは N+1 台のディスクに分散して保存され、特定のディスクが特定の役割を果たすことはありません。
読み込みと書き込み性能は RAID-4 と同様です。繰り返しになりますが、RAID-5 システムは (N+1 台のディスクの内) 最大で 1 台までに障害が起きても動作します。
RAID-6
RAID-6 は RAID-5 の拡張と考えられます。RAID-6 では、N 個のブロックのそれぞれに対して 2 個の冗長性ブロックを使います。この N+2 個のブロックは N+2 台のディスクに分散して保存されます。
RAID-6 は RAID-4 と RAID-5 に比べて少し高価ですが、追加的な安全策を講じる事が可能です。なぜなら、(N+2 台中の) 最大で 2 台までの障害に対してデータを守る事が可能だからです。書き込み操作は 1 つのデータブロックと 2 つの冗長性ブロックを書き込むことになりますから、書き込み性能が更に遅くなります。
RAID-1+0
厳密に言えば RAID-1+0 は RAID レベルではなく、2 種類の RAID 分類を積み重ねたものです。2×N 台のディスクが必要で、最初に 2 台毎のペアから N 台の RAID-1 ボリュームを作ります。N 台の RAID-1 ボリュームは「リニア RAID」か LVM (次第にこちらを選ぶケースが増えています) のどちらか一方を使って 1 台に統合されます。LVM を使うと純粋な RAID ではなくなりますが、LVM を使っても問題はありません。
RAID-1+0 は復数のディスク障害を乗り切る事が可能です: 上に挙げた 2×N アレイの内最大で N 台までの障害に耐えます。ただし、各 RAID-1 ペアの内少なくとも 1 台のディスクが動き続けなければいけません。
明らかに、RAID レベルは各用途からの制限および要求に従って選択されます。1 台のコンピュータに、異なる設定を持つ復数の RAID アレイを配置する事が可能である点に注意してください。

12.1.1.2. RAID の設定

RAID ボリュームを設定するには mdadm パッケージが必要です; mdadm パッケージには、RAID アレイを作成したり操作するための mdadm コマンド、システムの他の部分に RAID アレイを統合するためのスクリプトやツール、監視システム、が含まれます。
以下の例では、多数のディスクを持つサーバをセットアップします。ディスクの一部は既に利用されており、残りは RAID をセットアップするために利用可能になっています。最初の状態で、以下のディスクとパーティションが存在します:
  • sdb ディスク、4 GB、は全部利用可能です;
  • sdc ディスク、4 GB、も全部利用可能です;
  • sdd ディスクでは、sdd2 (約 4 GB) パーティションだけが利用可能です。
  • 最後に、sde ディスク、4 GB、全部利用可能です。
2 つのボリューム、RAID-0 とミラー (RAID-1)、を作るためにこれらの物理ディスクを使います。RAID-0 ボリュームから始めましょう:
# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jan 17 15:56:55 2013
     Raid Level : raid0
     Array Size : 8387584 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 15:56:55 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : mirwiz:0  (local to host mirwiz)
           UUID : bb085b35:28e821bd:20d697c9:650152bb
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
524288 inodes, 2096896 blocks
104844 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2147483648
64 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
       32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.9G  146M  7.4G   2% /srv/raid-0
mdadm --create コマンドは復数のパラメータを要求します: 作成するボリュームの名前 (/dev/md*、MD は Multiple Device を意味します)、RAID レベル、ディスク数 (普通この値は RAID-1 とそれ以上のレベルでのみ意味があるにも関わらず、これは必須オプションです)、利用する物理デバイス。デバイスを作成したら、デバイスを通常のパーティションを取り扱うのと同様のやり方で取り扱う事が可能です。ファイルシステムを作成したり、ファイルシステムをマウントしたり、する事が可能です。作成する RAID-0 ボリュームに md0 と名前をつけたのは偶然に過ぎない点に注意してください。アレイの番号付けと冗長性の度合いを関連付ける必要はありません。また、/dev/md0 の代わりに /dev/md/linear のような mdadm パラメータを使えば、名前付き RAID アレイを作成する事も可能です。
同様のやり方を使って RAID-1 を作成します。注意するべき違いは作成後に説明します;
# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Thu Jan 17 16:13:04 2013
     Raid Level : raid1
     Array Size : 4192192 (4.00 GiB 4.29 GB)
  Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 16:13:04 2013
          State : clean, resyncing (PENDING) 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       8       64        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
          State : clean
[...]
幾つかの注意点があります。最初に、mdadm は物理デバイス同士のサイズが異なる点を指摘しています; この事によりサイズが大きい側のデバイスの一部の領域が使えなくなるため、確認が求められています。
更に重要な事は、ミラーの状態に注意する事です。RAID ミラーの正常な状態とは、両方のディスクが全く同じ内容を持っている状態です。しかしながら、ボリュームを最初に作成した直後、RAID ミラーは正常な状態である事を保証されません。このため、RAID サブシステムは RAID ミラーの正常な状態を保証するために、RAID デバイスが作成されたらすぐに同期化作業を始めます。暫くの後 (必要な時間はディスクの実サイズに依存します…)、RAID アレイは「active」状態に移行します。同期化作業中、ミラーは信頼性低下状態で、冗長性は保証されない点に注意してください。同期化作業中にディスク障害が起きると、すべてのデータを失うことにつながる恐れがあります。しかしながら、最近作成された RAID アレイの最初の同期化作業の前に、大量の重要なデータがこの RAID アレイに保存されていることはほとんど無いでしょう。信頼性低下状態であっても、/dev/md1 は利用可能で、ファイルシステムを作成したり、データのコピーを取ったりする事が可能、という点に注意してください。
RAID-1 アレイを構成するディスクの 1 台に障害が発生した場合、何が起きるかを見て行きましょう。mdadm--fail オプションを付けることで、ディスク障害を模倣する事が可能です:
# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Thu Jan 17 16:14:09 2013
          State : active, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 19

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       0        0        1      removed

       1       8       64        -      faulty spare   /dev/sde
ボリュームの内容はまだアクセスする事が可能 (そして、ボリュームがマウントされていた場合、アプリケーションはディスク障害に気が付きません) ですが、データの安全性はもはや保証されません: sdd ディスクに障害が発生した場合、データは失われます。この危険性を避けるために、我々は障害の発生したディスクを新しいディスク sdf に交換します:
# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 16:15:32 2013
          State : clean, degraded, recovering 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Rebuild Status : 28% complete

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 26

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      spare rebuilding   /dev/sdf

       1       8       64        -      faulty spare   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Thu Jan 17 16:16:36 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

       1       8       64        -      faulty spare   /dev/sde
繰り返しになりますが、ボリュームはまだアクセスする事が可能ですが、ボリュームが信頼性低下状態ならば、カーネルは自動的に再構成作業を実行します。再構成作業が終了したら、RAID アレイは正常状態に戻ります。ここで、システムに sde ディスクをアレイから削除する事を伝える事が可能です。削除することで、2 台のディスクからなる古典的な RAID ミラーになります:
# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf
この後、今後サーバの電源を切った後にドライブを物理的に取り外したり、ハードウェア設定がホットスワップに対応しているならばホットリムーブする事が可能です。一部の SCSI コントローラ、ほとんどの SATA ディスク、USB や Firewire で接続された外部ドライブ等はホットスワップに対応しています。

12.1.1.3. 設定のバックアップ

RAID ボリュームに関連するメタデータのほとんどはアレイを構成するディスク上に直接保存されています。このため、カーネルはアレイとその構成要素を検出し、システムの起動時に自動的にアレイを組み立てる事が可能です。しかしながら、この設定をバックアップする事を推奨します。なぜなら、この検出機構は不注意による間違いを防ぐものでは無いからです。そして、注意して取り扱うべき状況ではまさに検出機構が上手く働かない事が見込まれます。上の例で、sde ディスク障害が本物で (模倣でない)、sde ディスクを取り外す前にシステムを再起動した場合、sde ディスクは再起動中に検出され、システムに復帰します。カーネルは 3 つの物理ディスクを検出し、それぞれのディスクが同じ RAID ボリュームの片割れであると主張します。さらに別の混乱する状況が考えられます。2 台のサーバで使われていた RAID ボリュームを片方のサーバに集約する事を考えてみましょう。ディスクが移動される前、各アレイは正常に実行されていました。カーネルはアレイを検出して、適切なペアを組み立てる事が可能です; しかし、片方のサーバに移動されたディスクが前のサーバでは md1 に組み込まれており、さらに新しいサーバが既に md1 という名前のアレイを持っていた場合、どちらか一方の名前が変えられます。
このため、参考情報に過ぎないとはいえ、設定を保存することは重要です。設定を保存する標準的な方法は /etc/mdadm/mdadm.conf ファイルを編集する事です。以下に例を示します:

例12.1 mdadm 設定ファイル

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3
最も役に立つ設定項目の 1 つに DEVICE オプションがあります。これは起動時にシステムが RAID ボリュームの構成情報を自動的に探すデバイスをリストします。上の例では、デフォルト値 partitions containers を置き替え、デバイスファイルを明示したリストにしました。なぜなら、パーティションだけでなくすべてのディスクをボリュームとして使うように決めたからです。
上の例における最後の 2 行を使うことで、カーネルはアレイに割り当てるボリューム番号を安全に選ぶ事が可能です。ディスク本体に保存されたメタ情報はボリュームを再度組み上げるのに十分ですが、ボリューム番号を定義する (そして /dev/md* デバイス名にマッチする事を確認する) には不十分です。
幸いなことに、この行を自動的に生成する事が可能です:
# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464
最後の 2 行の内容はボリュームを構成するディスクのリストに依存しません。このため、障害の発生したディスクを新しいディスクに交換した際に、これを改めて生成する必要はありません。逆に、RAID アレイを作成および削除した際に、必ずこの設定ファイルを注意深く更新する必要があります。

12.1.2. LVM

LVM、Logical Volume Manager、は物理ディスクから論理ボリュームを抽象化する別のアプローチで、信頼性を増加させるのではなく柔軟性を増加させることに注目しています。LVM を使うことで、アプリケーションから見る限り透過的に論理ボリュームを変更する事が可能です; 例えば LVM は、新しいディスクを追加し、データを新しいディスクに移行し、古いディスクを削除する事が、ボリュームをアンマウントせずに可能です。

12.1.2.1. LVM の概念

LVM の柔軟性は 3 つの概念から成る、抽象化レベルによって達成されます。
最初に、PV (物理ボリューム) はハードウェアに最も近い物です: PV はディスクのパーティション、ディスク全体、その他の任意のブロックデバイス (例えば、RAID アレイ) などの物理的要素です。物理的要素を LVM の PV に設定した場合、物理的要素へのアクセスは必ず LVM を介すべきという点に注意してください。そうでなければ、システムが混乱します。
復数の PV は VG (ボリュームグループ) にクラスタ化する事が可能です。VG は仮想的ディスクや拡張可能なディスクと比較されます。VG は概念的なもので、/dev 階層のデバイスファイルに現れません。そのため、VG を直接的に操作する危険はありません。
3 番目のオブジェクトは LV (論理ボリューム) です。LV は VG の塊です; VG をディスクと比較する類推に従って考えると、LV はパーティションと比較されます。LV はブロックデバイスとして /dev に現れ、他の物理パーティションと同様に取り扱う事が可能です (一般的に言って、ファイルシステムやスワップ領域を作成する事が可能です)。
重要な事柄は、VG を LV に分割する場合に物理的要素 (PV) はいかなる制約も要求しないという点です。1 つの物理的要素 (例えばディスク) から構成される VG は復数の論理ボリュームに分割できます; 同様に、VG に復数の物理ディスクを参加させ、VG を 1 つの大きな論理ボリュームとして提供する事が可能です。明らかに、たった 1 つの制約事項は各 LV に割り当てるサイズの合計が、LV が所属するボリュームグループの PV の合計サイズを超える事ができないという点です。
しかしながら、 VG を構成する物理的要素の特徴を一致させること、各論理ボリュームの用途に対する要求性能を考慮しながら VG を論理ボリュームに分割すること、は通常理にかなった方針です。例えば、利用可能なハードウェアに高速なディスクと低速なディスクがある場合、高速なディスクから構成される VG と低速なディスクから構成される VG に分ける事が可能です; 高速なディスクから構成される VG に含まれる論理ボリュームを高速なデータアクセスを必要とするアプリケーションに割り当て、低速なディスクから構成される VG に含まれる論理ボリュームを負荷の少ない作業用に割り当てます。
如何なる場合でも、LV は特定の PV に所属しない事を忘れないで下さい。ある LV に含まれるデータが物理的に保存されている場所を操作する事も可能ですが、普通に使っている限りその必要はありません。逆に: VG を構成する一連の物理的要素が変化する場合、特定の LV に対応する物理ストレージの場所がディスク上で変化する事が可能です (もちろん、変化の範囲は対象の VG を構成する PV の中に限られます)。

12.1.2.2. LVM の設定

典型的な用途に対する LVM の設定過程を、段階的に見て行きましょう: 複雑なストレージの状況を単純化したい場合です。通常、長く複雑な一時的措置を繰り返した挙句の果てに、この状況に陥る事があります。説明目的で、徐々にストレージを変更する必要のあったサーバを考えます。このサーバでは、復数の一部使用済みディスクに、利用可能なパーティションが分けられています。より具体的に言えば、以下のパーティションが利用可能です:
  • sdb ディスク上に、sdb2 パーティション、4 GB;
  • sdc ディスク上に、sdc3 パーティション、3 GB;
  • sdd ディスク、4 GB、は全領域を利用可能;
  • sdf ディスク上に、sdf1 パーティション、4 GB; および sdf2 パーティション、5 GB。
加えて、sdbsdf が他の 2 台に比べて高速であると仮定しましょう。
我々の目標は、3 種類の異なるアプリケーション用に 3 つの論理ボリュームを設定する事です: 5 GB のストレージ領域が必要なファイルサーバ、データベース (1 GB)、バックアップ用の領域 (12 GB) です。ファイルサーバとデータベースは高い性能を必要とします。しかし、バックアップはアクセス速度をそれほど重要視しません。これらすべての制約事項により、各アプリケーションの使うパーティションが制限されます; LVM を使うことで、デバイスの物理的サイズをまとめる事が可能です。このため、利用可能な領域の合計だけが制限です。
必要なツールは lvm2 パッケージとその依存パッケージに含まれています。これらのパッケージをインストールしたら、3 つの手順を踏んで LVM をセットアップします。各手順は LVM の概念の 3 つのレベルに対応します。
最初に、pvcreate を使って物理ボリュームを作成します:
# pvdisplay
# pvcreate /dev/sdb2
  Writing physical volume data to disk "/dev/sdb2"
  Physical volume "/dev/sdb2" successfully created
# pvdisplay
  "/dev/sdb2" is a new physical volume of "4.00 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb2
  VG Name               
  PV Size               4.00 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
  Writing physical volume data to disk "/dev/sdc3"
  Physical volume "/dev/sdc3" successfully created
  Writing physical volume data to disk "/dev/sdd"
  Physical volume "/dev/sdd" successfully created
  Writing physical volume data to disk "/dev/sdf1"
  Physical volume "/dev/sdf1" successfully created
  Writing physical volume data to disk "/dev/sdf2"
  Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
  PV         VG   Fmt  Attr PSize PFree
  /dev/sdb2       lvm2 a--  4.00g 4.00g
  /dev/sdc3       lvm2 a--  3.09g 3.09g
  /dev/sdd        lvm2 a--  4.00g 4.00g
  /dev/sdf1       lvm2 a--  4.10g 4.10g
  /dev/sdf2       lvm2 a--  5.22g 5.22g
ここまでは順調です; PV はディスク全体およびディスク上の各パーティションに対して設定する事が可能です。上に示した通り、pvdisplay コマンドは既存の PV をリストします。出力フォーマットは 2 種類あります。
vgcreate を使って、これらの物理的要素から VG を構成しましょう。高速なディスクの PV から vg_critical VG を構成します; これ以外の低速なディスクを含む PV から vg_normal VG を構成します。
# vgdisplay
  No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
  Volume group "vg_critical" successfully created
# vgdisplay
  --- Volume group ---
  VG Name               vg_critical
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               8.09 GiB
  PE Size               4.00 MiB
  Total PE              2071
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2071 / 8.09 GiB
  VG UUID               bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
  Volume group "vg_normal" successfully created
# vgdisplay -C
  VG          #PV #LV #SN Attr   VSize  VFree 
  vg_critical   2   0   0 wz--n-  8.09g  8.09g
  vg_normal     3   0   0 wz--n- 12.30g 12.30g
繰り返しになりますが、コマンドはかなり簡潔です (vgdisplay には 2 種類の出力フォーマットがあります)。同じ物理ディスクの 2 つのパーティションを 2 つの異なる VG に割り当てる事が可能である点に注意してください。また、vg_ 接頭辞を VG の名前に使っていますが、これは慣例に過ぎない点に注意してください。
これでサイズが約 8 GB と 12 GB の 2 台の「仮想ディスク」を手に入れたことになります。それでは仮想ディスクを「仮想パーティション」(LV) に分割しましょう。これを行うには lvcreate コマンドを少し複雑な構文で実行します:
# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
  Logical volume "lv_files" created
# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_critical/lv_files
  LV Name                lv_files
  VG Name                vg_critical
  LV UUID                J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
  LV Write Access        read/write
  LV Creation host, time mirwiz, 2013-01-17 17:05:13 +0100
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
  Logical volume "lv_backups" created
# lvdisplay -C
  LV         VG          Attr     LSize  Pool Origin Data%  Move Log Copy%  Convert
  lv_base    vg_critical -wi-a---  1.00g                                           
  lv_files   vg_critical -wi-a---  5.00g                                           
  lv_backups vg_normal   -wi-a--- 12.00g
論理ボリュームを作成する場合、2 種類のパラメータが必要です; 必ず 2 種類のパラメータをオプションとして lvcreate に渡します。作成する LV の名前を -n オプションで指定し、サイズを -L オプションで指定します。また、操作対象の VG をコマンドに伝える事が必要です。これはもちろん最後のコマンドラインパラメータです。
論理ボリュームが作成され、ブロックデバイスファイルとして /dev/mapper/ に現れます:
# ls -l /dev/mapper
合計 0
crw------T 1 root root 10, 236  1月 17 16:52 control
lrwxrwxrwx 1 root root       7  1月 17 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7  1月 17 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7  1月 17 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0  1月 17 17:05 /dev/dm-0
brw-rw---T 1 root disk 253, 1  1月 17 17:05 /dev/dm-1
brw-rw---T 1 root disk 253, 2  1月 17 17:05 /dev/dm-2
分かり易くするために、VG に対応するディレクトリの中に便利なシンボリックリンクが作成されます:
# ls -l /dev/vg_critical
合計 0
lrwxrwxrwx 1 root root 7  1月 17 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7  1月 17 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
合計 0
lrwxrwxrwx 1 root root 7  1月 17 17:05 lv_backups -> ../dm-2
LV は標準的なパーティションと全く同じように取り扱われます:
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
ファイルシス                     サイズ  使用  残り 使用% マウント位置
/dev/mapper/vg_normal-lv_backups    12G  158M   12G    2% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base    /srv/base       ext4
/dev/vg_critical/lv_files   /srv/files      ext4
/dev/vg_normal/lv_backups   /srv/backups    ext4
アプリケーションにしてみれば、無数の小さなパーティションがわかり易い名前を持つ 1 つの大きな 12 GB のボリュームにまとめられたことになります。

12.1.2.3. LVM の経時変化

パーティションや物理ディスクを統合する機能は便利ですが、これは LVM のもたらす主たる利点ではありません。ボリュームを進化させる必要が生じた場合に、LVM のもたらす柔軟性が時間経過に伴い特に重要視されるようになります。我々の例で、新たに巨大なファイルを保存したいけれども、ファイルサーバ専用の LV はこの巨大なファイルを保存するには狭すぎる、と仮定しましょう。我々はまだ vg_critical で利用可能な全領域を使い切っていないので、lv_files のサイズを増やす事が可能です。この目的のために lvresize コマンドを使い、ボリュームのサイズの変化にファイルシステムを対応させるために resize2fs を使います。
# df -h /srv/files/
ファイルシス                     サイズ  使用  残り 使用% マウント位置
/dev/mapper/vg_critical-lv_files   5.0G  4.6G  146M   97% /srv/files
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   2   2   0 wz--n- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
  Extending logical volume lv_files to 7.00 GB
  Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/vg_critical/lv_files to 1835008 (4k) blocks.
The filesystem on /dev/vg_critical/lv_files is now 1835008 blocks long.

# df -h /srv/files/
ファイルシス                     サイズ  使用  残り 使用% マウント位置
/dev/mapper/vg_critical-lv_files   6.9G  4.6G  2.1G   70% /srv/files
データベースをホストしているボリュームを拡張するために、同じやり方を使います。VG の利用可能な領域は既にほぼ使い切った状態になっています:
# df -h /srv/base/
ファイルシス                    サイズ  使用  残り 使用% マウント位置
/dev/mapper/vg_critical-lv_base  1008M  854M  104M   90% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree 
  vg_critical   2   2   0 wz--n- 8.09g 92.00m
どんな状況であっても、LVM を使っていれば物理ボリュームを既存のボリュームグループに追加する事が可能です。例えば、今までは LVM の外で管理されていた sdb1 パーティションには、lv_backups に移動可能なアーカイブだけが含まれていた点に気が付いたとしましょう。このため、sdb1 パーティションを再利用し、ボリュームグループに統合させる事が可能です。その結果、利用可能な領域を増やす事が可能です。これが vgextend コマンドの目的です。もちろん、sdb1 パーティションを物理ボリュームとして準備しなければいけません。VG を拡張したら、先と同様のコマンドを使って先に論理ボリュームを増加させ、その後にファイルシステムを増加させます:
# pvcreate /dev/sdb1
  Writing physical volume data to disk "/dev/sdb1"
  Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   3   2   0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
ファイルシス                    サイズ  使用  残り 使用% マウント位置
/dev/mapper/vg_critical-lv_base   2.0G  854M  1.1G   45% /srv/base

12.1.3. RAID それとも LVM?

RAID と LVM はどちらも、用途が変わらない 1 台のハードディスクを備えたデスクトップコンピュータの単純なケースではすぐに、疑う余地のない利点をもたらします。しかしながら、RAID と LVM は目標を分岐させて別々の道を歩んでいます。どちらを使うべきか悩むのは間違っていることではありません。最も適切な答えは、もちろん現在の要求と将来予測される要求に依存します。
幾つかの状況では、疑問の余地がないくらい簡単に答えを出す事が可能です。ハードウェア障害からデータを保護す事が求められる場合、ディスクの冗長性アレイ上に RAID をセットアップするのは明らかです。なぜなら LVM はこの種の問題に全く対処しないからです。逆に、柔軟なストレージ計画が必要でディスクの物理的な配置に依存せずにボリュームを構成したい場合、RAID はあまり役に立たず LVM はを選ぶのが自然です。
3 番目の注目すべき利用形態は単に 2 つのディスクを 1 つのボリュームにまとめる場合です。これは性能が欲しかったり、利用可能なディスクのどれよりも大きな単一のファイルシステムにするという理由が考えられます。この場合、RAID-0 (またはリニア RAID) か LVM ボリュームを使って対処できます。この状況では、追加的な制約事項 (例えば、残りのコンピュータが RAID だけを使っている場合に RAID を使わなければいけないなど) が無ければ、通常 LVM を選択します。LVM の最初のセットアップは RAID に比べて複雑ですが、LVM は複雑度を少し増加させるだけで、要求が変った場合や新しいディスクを追加する必要ができた場合に対処可能な、追加的な柔軟性を大きく上昇させます。
そしてもちろん、本当に興味深い利用形態はストレージシステムにハードウェア障害に対する耐性を持たせさらにボリューム割り当てに対する柔軟性を持たせる必要がある場合です。RAID と LVM のどちらも片方だけで両方の要求を満足させることは不可能です; つまり、RAID と LVM の両方を同時に使用する、というより一方の上に他方を構成する方針を採用すべき場面です。RAID と LVM は成熟しているため、この方針はほぼ標準的になりつつあります。この方針では、最初にディスクを少数の大きな RAID アレイにグループ分けして、それらの RAID アレイを LVM 物理ボリュームとして使うことにより、データの冗長性を確保します; 論理パーティションはファイルシステム用の LV から分配されます。この方針の売りは、ディスク障害が起きた場合に再構築しなければいけない RAID アレイの数が少ない点です。このため、管理者は復旧に必要な時間を減らす事が可能です。
具体例を見てみましょう: Falcot Corp の広報課では、動画編集用にワークステーションが必要ですが、広報課の予算の都合上、最初から高性能のハードウェアに投資する事が不可能です。グラフィック性能を担うハードウェア (モニタとビデオカード) に大きな予算を割き、ストレージ用には一般的なハードウェアを使うように決定されました。しかしながら、広く知られている通り、デジタルビデオ用のストレージはある種の条件を必要とします: 保存されるデータのサイズが大きく、このデータを読み込みおよび書き込みする際の処理速度がシステム全体の性能にとって重要 (例えば、平均的なアクセス時間よりも重要) です。この条件を一般的なハードウェアを使って満足させます。この場合 2 台の SATA ハードディスクドライブを使います; システムデータと一部のユーザデータはハードウェア障害に対する耐性を持たせる必要があります。編集済みのビデオクリップを保護しなければいけませんが、編集前のビデオ素材をそれほど気にする必要はありません。なぜなら、編集前のビデオ素材はまだビデオテープで残されているからです。
前述の条件を満足させるために RAID-1 と LVM を組み合わせます。ディスクの並行アクセスを最適化し、そして障害が同時に発生する危険性を減らすために、各ディスクは 2 つの異なる SATA コントローラに接続されています。このため、各ディスクは sdasdc として現れます。以下の方針で示す通り、全く同一の方法でパーティショニングされます:
# fdisk -l /dev/sda

Disk /dev/hda: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00039a9f

   Device Boot      Start      End      Blocks   Id  System
/dev/sda1   *           1      124      995998+  fd  Linux raid autodetect
/dev/sda2             125      248      996030   82  Linux swap / Solaris
/dev/sda3             249    36483   291057637+   5  Extended
/dev/sda5             249    12697    99996561   fd  Linux raid autodetect
/dev/sda6           12698    25146    99996561   fd  Linux raid autodetect
/dev/sda7           25147    36483    91064421   8e  Linux LVM
  • 両方のディスクの最初のパーティション (約 1 GB) は RAID-1 ボリューム md0 に組み込まれます。このミラーは root ファイルシステムを保存するために直接的に使われます。
  • sda2sdc2 パーティションは swap パーティションとして使われます。スワップ領域のサイズは合計で 2 GB になります。RAM のサイズは 1 GB で、ワークステーションで利用可能なメモリサイズは十分な量と言えます。
  • sda5sdc5 パーティションおよび sda6sdc6 パーティションは、それぞれ約 100 GB の 2 つの新しい RAID-1 ボリューム md1md2 に組み上げられます。これらのミラーは LVM の物理ボリュームとして初期化され、vg_raid ボリュームグループに割り当てられます。vg_raid VG は約 200 GB の安全な領域になります。
  • 残りのパーティションである sda7sdc7 は直接的に物理ボリュームとして使われ、vg_bulk と呼ばれる別の VG に割り当てられます。これはおよそ 200 GB の領域になります。
VG を作成したら、VG をとても柔軟な方法でパーティショニングする事が可能です。vg_raid に作成された LV は 1 台にディスク障害に対して耐性を持ちますが、vg_bulk の場合そうではない点を忘れないで下さい; 逆に、vg_bulk は両方のディスクに渡って割り当てられるので、巨大なファイルの読み書き速度が高速化されるでしょう。
lv_usrlv_varlv_home という LV を vg_raid に作成し、それぞれに対応するファイルシステムをホストするようにします; 別の大きな LV lv_movies は編集済みの最終版の映像をホストするために使われます。vg_bulk を、デジタルビデオカメラから取り出したデータ用の大きな lv_rushes と、一時ファイル用の lv_tmp、に分割します。作業領域を作成する場所は簡単に決められるものではありません: 作業領域用のボリュームは良い性能を必要としますが、編集作業中にディスク障害が起きた場合に作業内容を保護する必要があるでしょうか? この質問の回答次第で、対応する LV を vg_raidvg_bulk のどちらの VG に作成するかが決まります。
これで、重要なデータ用に多少の冗長性と、利用可能な領域が用途ごとにどのように分割されるかに関する大きな柔軟性が確保されました。後から (例えば音声クリップの編集用に) 新しいソフトウェアをインストールする場合も、/usr/ をホストしている LV を簡単に増加する事が可能です。