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 アレイを標準的な物理ディスクとして機能する単一のディスクとみなします。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 : Wed May  6 09:24:34 2015
     Raid Level : raid0
     Array Size : 8387584 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Wed May  6 09:24:34 2015
          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.12 (29-Aug-2014)
Creating filesystem with 2095104 4k blocks and 524288 inodes
Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6
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
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/md0         7.9G   18M  7.4G    1% /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 : Wed May  6 09:30:19 2015
     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 : Wed May  6 09:30:40 2015
          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」または「clean」状態に移行します。同期化作業中、ミラーは信頼性低下状態で、冗長性は保証されない点に注意してください。同期化作業中にディスク障害が起きると、すべてのデータを失うことにつながる恐れがあります。しかしながら、最近作成された 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 : Wed May  6 09:39:39 2015
          State : clean, 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
       2       0        0        2      removed

       1       8       64        -      faulty   /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 : Wed May  6 09:48:49 2015
          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   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Wed May  6 09:49:08 2015
          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   /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、論理ボリュームマネージャ、は物理ディスクから論理ボリュームを抽象化する別のアプローチで、信頼性を増加させるのではなく柔軟性を増加させることに注目しています。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
  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
  Physical volume "/dev/sdc3" successfully created
  Physical volume "/dev/sdd" successfully created
  Physical volume "/dev/sdf1" successfully created
  Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
  PV         VG   Fmt  Attr PSize PFree
  /dev/sdb2       lvm2 ---  4.00g 4.00g
  /dev/sdc3       lvm2 ---  3.09g 3.09g
  /dev/sdd        lvm2 ---  4.00g 4.00g
  /dev/sdf1       lvm2 ---  4.10g 4.10g
  /dev/sdf2       lvm2 ---  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, 2015-06-10 06:10:50 -0400
  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%  Meta%  Move Log Cpy%Sync  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------- 1 root root 10, 236  6月 10 16:52 control
lrwxrwxrwx 1 root root       7  6月 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7  6月 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7  6月 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0  6月 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1  6月 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2  6月 10 17:05 /dev/dm-2
分かり易くするために、VG に対応するディレクトリの中に便利なシンボリックリンクが作成されます。
# ls -l /dev/vg_critical
合計 0
lrwxrwxrwx 1 root root 7  6月 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7  6月 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
合計 0
lrwxrwxrwx 1 root root 7  6月 10 17:05 lv_backups -> ../dm-2
LV は標準的なパーティションと全く同様に取り扱われます。
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
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   30M   12G    1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base    /srv/base       ext4 defaults 0 2
/dev/vg_critical/lv_files   /srv/files      ext4 defaults 0 2
/dev/vg_normal/lv_backups   /srv/backups    ext4 defaults 0 2
アプリケーションにしてみれば、無数の小さなパーティションがわかり易い名前を持つ 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%  Meta%  Move Log Cpy%Sync  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
  Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
  Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync  Convert
  lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) 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
  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/sda: 300 GB, 300090728448 bytes, 586114704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00039a9f

Device    Boot     Start       End   Sectors Size Id Type
/dev/sda1 *         2048   1992060   1990012 1.0G fd Linux raid autodetect
/dev/sda2        1992061   3984120   1992059 1.0G 82 Linux swap / Solaris
/dev/sda3        4000185 586099395 582099210 298G 5  Extended
/dev/sda5        4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6      203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7      403970491 586099395 182128904  93G 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 を簡単に増加することが可能です。