LVM

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page LVM and the translation is 80% complete.


Not to be confused with LLVM.

LVM (Logical Volume Manager) は、管理者がファイルシステムと具体的物理ストレージの間に抽象レイヤを提供するメタデバイスを作ることを可能にします。メタデバイス (その上にファイルシステムが構成される) は 論理ボリューム(logical volumes)と呼ばれ、それがボリュームグループ(volume groups)と呼ばれるストレージのプールから領域を使います。 ボリュームグループは1つまたは2つ以上の物理ボリューム(physical volume)から成っており、それがデータが保存される本当のデバイスです。

物理ボリュームはパーティション、JBOD(Just a Bunch Of Disks)によってグループ化されたハードドライブ全体、RAID、iSCSI、ファイバーチャンネル、eSATAなどがあり得ます。

インストール

LVMはデバイスドライバとユーザー空間のアプリケーション双方によって処理され、LVMの設定は行われます。

カーネル

次のカーネルオプションを有効化してください:

KERNEL linux-4.9 LVM を有効化する
Device Drivers  --->
   Multiple devices driver support (RAID and LVM)  --->
       <*> Device mapper support
           <*> Crypt target support
           <*> Snapshot target
           <*> Mirror target
           <*> Multipath target
               <*> I/O Path Selector based on the number of in-flight I/Os
               <*> I/O Path Selector based on the service time
Note
すべてを有効化する必要はありません。いくつかのオプションはLVM2 Snapshots と LVM2 Thin Snapshots, LVM2 Mirrors, LVM2 RAID 0/Stripeset と暗号化にのみ必要です。

USE フラグ

USE flags for sys-fs/lvm2 User-land utilities for LVM2 (device-mapper) software

lvm Build all of LVM2, not just device-mapper
lvm2create-initrd Install lvm2create_initrd script and pull in sys-apps/makedev for the /sbin/MAKEDEV command
readline Enable support for libreadline, a GNU line-editing library that almost everyone wants
sanlock Enable lvmlockd with support for sanlock
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
static !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically
static-libs Build static versions of dynamic libraries as well
systemd Enable use of systemd-specific libraries and features like socket activation or session tracking
thin Support for thin volumes
udev Enable virtual/udev integration (device discovery, power and storage device support, etc)

Emerge

USE フラグを確認したら、sys-fs/lvm2 パッケージをインストールするように Portage に指示してください:

root #emerge --ask sys-fs/lvm2

設定

LVMの設定はいくつかのレベルにおいて行われます:

  1. 専用ユーティリティでのLV, PV と VG設定;
  2. 設定ファイルによるLVMサブシステムの微調整;
  3. ディストリビューションレベルのサービスの設定;
  4. initramfs時のセットアップ.

論理ボリュームや物理ボリューム、ボリュームグループの扱いは使い方の章にて取り上げます。

LVM設定ファイル

LVMは/etc/lvm/lvm.confに大きな設定ファイルを用意しています。ほとんどのユーザーはLVMを使い始めるにあたってこのファイルの設定を修正する必要はないでしょう。

サービス管理

Gentoo は、ボリュームグループと論理ボリュームを自動的に検出してアクティブにする LVM サービスを提供しています。

サービスは、init システムを介して管理することができます。

openrc

LVMを手動で起動するには:

root #/etc/init.d/lvm start

ブート時にLVMを起動するには:

root #rc-update add lvm boot

systemd

LVMを手動で起動するには:

root #systemctl start lvm2-monitor.service

ブート時にLVMを起動するには:

root #systemctl enable lvm2-monitor.service

initramfsの中でLVMを使う

ほとんどのブートローダは直接LVMから起動することはできません - GRUBレガシーもLILOもです。 GRUB2は、LVMリニア論理ボリューム、ミラー化論理ボリュームとおそらくいくつかの種類のRAID論理ボリュームから起動することができます。現時点で、シンプロビジョニングされた論理ボリュームをサポートするブートローダはありません。

それにより、LVMでない/bootパーティションを使いLVMのルートパーティションをinitramfsからマウントすることが推奨されています。initramfsはgenkernel または dracut を使って自動的に生成することができ、さらには手動でカスタム Initramfs として生成することもできます:

  • genkernelは全てのタイプからブート可能です。ただしシンプロビジョニングされたボリュームは除き(それがビルドホストからのsys-block/thin-provisioning-tools バイナリのビルドもコピーもしてなければ)、また、おそらくRAID10も除かれます。(RAID10サポートはLVM2 2.02.98が必要ですがgenkernelは2.02.89をビルドします。しかし、スタティックバイナリがあればそれらがコピーされます);
  • dracutは全てのタイプでブートするはずですが、もしホストがシンプロビジョニングルート上で動いている場合、シンプロビジョニングサポートがinitramfsにて必要です。

Genkernel

sys-kernel/genkernelをインストールしてください。genkernelがシステムバイナリを使うよう(でなければそのプライベートコピーがビルドされます)、静的USEフラグもパッケージsys-fs/lvm2で有効化されます。次の例はinitramfs(カーネル全体ではなく)をビルドし、LVMサポートを有効化します。

root #genkernel --lvm initramfs

genkernelのmanpageは、システム要件に応じて他のオプションの概要を説明します。

initrdはどのようにLVMを開始するか、パラメータを必要とします。そして彼らは他のカーネルパラメータと同じように提供されます。例えば:

FILE /etc/default/grubdolvmをカーネルパラメータとして追加
GRUB_CMDLINE_LINUX="dolvm"

Dracut

sys-kernel/dracut パッケージは RedHat プロジェクトから移植され、initramfs を生成する類似ツールを提供します。詳細については、Dracutを参照してください。一般に、次のコマンドは有効なデフォルト initramfs を生成します。

root #dracut -a lvm

initrdはどのようにLVMを開始するか、パラメータを必要とします。そして彼らは他のカーネルパラメータと同じように提供されます。例えば:

FILE /etc/default/grubカーネルパラメータへのLVMサポートの追加
GRUB_CMDLINE_LINUX="rd.lvm.vg=vol00"

dracutについてのLVMオプションの包括的リストはDracut Manualの一節をご覧ください。

使い方

LVMは次に示す3つの異なるレベルでストレージを構成します:

  • ハードドライブ、パーティション、RAID、物理ボリューム(PV)として初期化される他の種類のストレージ
  • 物理ボリューム(PV)はボリュームグループ(VG)中にグループ化される
  • 論理ボリューム(LV)はボリュームグループ(VG)中に管理される

PV (物理ボリューム)

物理ボリュームはLVMが構成される実際のハードウェアやストレージシステムやストレージです。

パーティショニング

Note
別々のパーティションをストレージのためにボリュームグループで使うことはディスク全体を単一LVMボリュームグループとして使うことが望まれてない場合に限り必要です。もしディスク全体を使うとなると、これをスキップしディスク全体を物理ボリュームとして設定してください。

LVM のパーティションタイプは 8e (Linux LVM) です。

例えば、fdisk/dev/sdaのパーティションのタイプを設定するには:

root #fdisk /dev/sda

fdisk では、n キーを使ってパーティションをつくり、それから t キーでパーティションタイプを 8e に変更してください。

PVを作成

物理ボリュームはpvcreateコマンドによって作成あるいは初期化されます。

例えば、次のコマンドは/dev/sda/dev/sdbの先頭パーティションに物理ボリュームをつくります:

root #pvcreate /dev/sd[ab]1

PVの一覧

pvdisplayコマンドによってシステムのアクティブな全ての物理ボリュームを得ることができます。

root #pvdisplay
 --- Physical volume ---
  PV Name               /dev/sda1
  VG Name               volgrp
  PV Size               160.01 GiB / not usable 2.31 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              40962
  Free PE               4098
  Allocated PE          36864
  PV UUID               3WHAz3-dh4r-RJ0E-5o6T-9Dbs-4xLe-inVwcV
  
 --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               volgrp
  PV Size               160.01 GiB / not usable 2.31 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              40962
  Free PE               40962
  Allocated PE          0
  PV UUID               b031x0-6rej-BcBu-bE2C-eCXG-jObu-0Boo0x

より多くの物理ボリュームについて表示したければ、pvscanは非アクティブの物理ボリュームを検知し、有効化します。

root #pvscan
  PV /dev/sda1  VG volgrp        lvm2 [160.01 GiB / 16.01 GiB free]
  PV /dev/sdb1  VG volgrp        lvm2 [160.01 GiB / 160.01 GiB free]
  Total: 2 [320.02 GB] / in use: 2 [320.02 GiB] / in no VG: 0 [0]

PVを削除する

LVMは自動的に(そうしないよう指示しない限り)全ての有効な物理ボリュームへデータを順に送ります。もし(ボリュームグループ内の)該当する論理ボリュームがある単一物理ボリュームのフリースペースの量より小さければ、その論理ボリューム用の全てのスペースがその(単一)物理ボリューム上に連続して確保されます。これはパフォーマンス上の理由です。

物理ボリュームがボリュームグループより削除される必要があるのであれば、データがまず物理ボリュームから除去される必要があります。pvmoveコマンドで物理ボリューム上の全てのデータが同一ボリュームグループの物理ボリュームに移されます。

root #pvmove -v /dev/sda1

このような動作は移動する必要があるデータの量に応じて時間がかかります。完了したらデバイス上に残されたデータはないはずです。pvdisplayによってどの論理ボリュームからも物理ボリュームがもはや使われていないことを確認してください。

次のステップは、pvremoveを使って物理ボリュームが"deselected"になった後に物理ボリュームをボリュームグループからvgreduceで削除することです。

root #vgreduce vg0 /dev/sda1 && pvremove /dev/sda1

VG (ボリュームグループ)

ボリュームグループ(VG)は多くの物理ボリュームをまとめ、デバイスファイルシステムに/dev/VG_NAMEとして表示します。ボリュームグループの名前は管理者によって決定されます。

VGを作成

次のコマンドはボリュームグループ"vg0"を/dev/sda1/dev/sdb1として割り当てられた2つの物理ボリュームからつくります。

root #vgcreate vg0 /dev/sd[ab]1

VGの一覧

全てのアクティブなボリュームグループを表示するにはvgdisplayコマンドを使ってください。

root #vgdisplay
  --- Volume group ---
  VG Name               vg0
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                6
  Open LV               6
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               320.02 GiB
  PE Size               4.00 MiB
  Total PE              81924
  Alloc PE / Size       36864 / 144.00 GiB
  Free  PE / Size       45056 /176.01 GiB
  VG UUID               mFPXj3-DdPi-7YJ5-9WKy-KA5Y-Vd4S-Lycxq3

ボリュームグループが見つからなければvgscanコマンドを使ってください。

root #vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "vg0" using metadata type lvm2

VGを拡張

管理者がストレージ・リソースのプールを使用できるようにボリューム・グループグループの物理ボリュームは、ファイルシステムに割り当てることができます。ボリュームグループが十分な記憶リソースを保持していない場合には、追加の物理ボリュームにボリュームグループを拡張する必要があります。

次の例はボリュームグループ "vg0"を物理ボリューム/dev/sdc1で拡張します。

root #vgextend vg0 /dev/sdc1

物理ボリュームを最初のように初期化する必要があることを忘れないでください!

VGの縮小

物理ボリュームをボリュームグループから削除する必要があるときは物理ボリューム上のまだ使われている全てのデータはそのボリュームグループ内の他の物理ボリュームに移動される必要があります。見てきたように、これはpvmoveコマンドによって行われ、その後物理ボリュームはvgrduceを使うことでボリュームグループから削除されます。

root #pvmove -v /dev/sdc1
root #vgreduce vg0 /dev/sdc1

VGの削除

ボリュームグループがもはや必要でない(あるいは、言い換えれば、それが表すストレージプールがもはや使われてなく、その中の物理ボリュームが他の目的で解放される必要がある)なら、ボリュームグループはvgremoveで削除されます。これは論理ボリュームがボリュームグループに存在しない場合と、プールからすでに除去された物理ボリューム以外の全てにのみ有効です。

root #vgremove vg0

LV (論理ボリューム)

論理ボリュームはシステムを利用可能にする最後のメタデバイスであり、通常、そこにファイルシステムを作成します。論理ボリュームはボリュームグループ中に作成・管理され、/dev/VG_NAME/LV_NAMEとして表示されます。ボリュームグループのように、論理ボリュームに使われる名前は管理者によって決定されます。

LVの作成

論理ボリュームをつくるためには、lvcreateコマンドが使われます。コマンドへのパラメータは論理ボリュームの要求サイズ(ただしボリュームグループ中の空き量量より大きくすることはできません)から成り、それによりボリュームグループ中にスペースが確保され、論理ボリュームの名前がつくられます。

次の例では、論理ボリューム"lvol1"はボリュームグループ"vg0"から150MBのサイズでつくられます。

root #lvcreate -L 150M -n lvol1 vg0

lvcreateにボリュームグループ内の全ての空き容量を使うよう指示することが可能です。これは(人間に可読の)サイズではなく"エクステント"の量を指示する-lオプションによって行われます。論理ボリュームはボリュームグループ内のデータの塊である"論理エクステント"に分割されます。ボリュームグループ内の全てのエクステントは同じサイズです。-lオプションでlvcreateに全ての未使用エクステントに割り当てるよう指示できます。

root #lvcreate -l 100%FREE -n lvol1 vg0

"FREE"の次の"VG"キーワードはボリュームグループ全体のサイズを示すために使われます。

LVの表示

全てのアクティブな論理ボリュームを表示するにはlvdisplayコマンドを使ってください。

root #lvdisplay

論理ボリュームがない場合、lvscanコマンドが全ての優子なボリュームグループ上の論理ボリュームをスキャンするのに使えます。

root #lvscan

LVを拡張

論理ボリュームを拡張する必要がある場合、lvextendコマンドは論理ボリュームの確保済みスペースを広げるのに使うことが出来ます。

例えば、論理ボリューム"lvol1"を計500MBに拡張するには:

root #lvextend -L500M /dev/vg0/lvol1

トータルサイズではなく追加サイズを指定することも可能です。

root #lvextend -L+350MB /dev/vg0/lvol1

拡張されたボリュームグループは直ちに追加のストレージをユーザーに提供するわけではありません。そのためには、ボリュームグループ上のファイルシステムを必要サイズだけ拡張する必要があります。もしファイルシステムがオンラインリサイズを許可しないばあい、問題のファイルシステムについてドキュメントを調べてください。

例えば、ext4ファイルシステムを500MBになるように拡張するには:

root #resize2fs /dev/vg0/lvol1 500M

一部のファイルシステムに対しては、lvresize が論理ボリュームとファイルシステムを同時に拡張します。例えば、論理ボリューム lvol1 を拡張し、その ext4 ファイルシステムをリサイズするには:

root #lvresize --resizefs --size +350GB /dev/vg0/lvol1

LVの縮小

論理ボリュームのサイズを縮小するには、まずファイルシステムそれ自体を縮小してください。。全てのファイルシステムがオンライン縮小をサポートしているわけではありません。

例えば、ext4はオンライン縮小をサポートしていないのでファイルシステムはまずアンマウントされる必要があります。問題を排除するためファイルシステムチェックを行うことが推奨されています。

root #umount /mnt/data
root #e2fsck -f /dev/vg0/lvol1
root #resize2fs /dev/vg0/lvol1 150M

縮小済みファイルシステムのもと、論理ボリュームを縮小することが可能です。

root #lvreduce -L150M /dev/vg0/lvol1

LV権限

LVMは論理ボリューム上での権限付与をサポートしています。

例えば、論理ボリュームはlvchangeコマンドにより"read only"にすることが可能です。

root #lvchange -p r /dev/vg0/lvol1
root #mount -o remount /dev/vg0/lvol1

変更が直ちに実行されるために再マウントが必要です。

論理ボリュームを再び書き込み可能にするためには、rw パーミッションビットを使ってください:

root #lvchange -p rw /dev/vg0/lvol1 && mount -o remount /dev/vg0/lvol1

LVを削除する

論理ボリュームを削除する前に、それがマウントされていないことを確認してください。

root #umount /dev/vg0/lvol1

さらなる書き込みが起こらないよう論理ボリュームを停止してください:

root #lvchange -a n /dev/vg0/lvol1

ボリュームがアンマウント・停止されたことで削除可能になり、ボリュームグループ内の他の論理ボリュームのためにエクステントを解放することができます。

root #lvremove /dev/vg0/lvol1

機能

LVMはストレージ管理者にたくさんのおもろい機能を提供しています。たとえば

  • シンプロビジョニング (ストレージのオーバーコミット)
  • スナップショット
  • 異なる領域確保方法によるボリュームタイプ

シンプロビジョニング

新しいバージョンの LVM2 (2.02.89) は、"シン"ボリュームをサポートしています。シンボリュームは、ファイルシステムにおけるスパースファイルの考え方を、ブロックデバイスについて適用したものです。シンボリュームの示すサイズは割り付けられたサイズよりも大きく取ることができ、プールよりも大きいサイズにすることさえできます。スパースファイルと同様に、このブロックデバイスの内容が成長するのにしたがって、エクステントが割り付けられていきます。ファイルシステムが discard 操作をサポートしている場合は、ファイルが削除されたときにエクステントが再び解放され、プールの使用率を削減します。

LVM においては、このようなシンプールは、中に論理ボリュームを配置できる特殊な種類の論理ボリュームとなっています。

シンプールを作成する

Warning
シンプールメタデータ内でオーバーフローが発生した場合、プールが壊れてしまうでしょう。LVM はこの状態から回復することができません
Note
シンプールが枯渇した場合、そのシンプールにさらにエクステントを割り付けさせ (ようとし) たプロセスは、そのシンプールが拡張されるかプロセスが SIGKILL を受け取るまで、"killable sleep" 状態に入って動かなくなります。

Each thin pool has metadata associated with it, which is added to the thin pool size. LVM will compute the size of the metadata based on the size of the thin pool as the minimum of pool_chunks * 64 bytes or 2MiB, whichever is larger. The administrator can select a different metadata size as well.

シンプールを作成するには、lvcreate--type thin-pool --thinpool thin_pool オプションを付与してください:

root #lvcreate -L 150M --type thin-pool --thinpool thin_pool vg0

上の例は、総サイズ 150 MB の thin_pool という名前のシンプールを作成します。これはシンプールのために実際に割り付けられるサイズです (つまり、使用できる実際のストレージの総容量です)。

明示的にメタデータサイズを指定するには、--metadatasize オプションを使用してください:

root #lvcreate -L 150M --poolmetadatasize 2M --type thin-pool --thinpool thin_pool vg0

シンプールに与えられたメタデータにより、論理ボリュームを作成するためにボリュームグループのすべての空き容量を使用する直観的な方法は動作しません (LVM のバグ 812726 を確認してください):

root #lvcreate -l 100%FREE --type thin-pool --thinpool thin_pool vg0
Insufficient suitable allocatable extents for logical volume thin_pool: 549 more required

シンプールは他の LV と異なり、対応するデバイスノードを持たないことに注意してください。

シン論理ボリュームを作成する

シン論理ボリュームは、シンプール (これ自体も論理ボリュームです) の中に存在する論理ボリュームです。シン論理ボリュームはスパースなので、-V オプションを使用して、物理サイズではなく仮想サイズを指定します:

root #lvcreate -T vg0/thin_pool -V 300M -n lvol1

この例では、(シン) 論理ボリューム lvol1 が、背後のプールには 150MB のストレージしか実際に割り付けられていないものの、300MB のサイズのデバイスとして見えるようになります。

シンプールと、そのシンプールの中の論理ボリュームを、ひとつのコマンドで同時に作成することもできます:

root #lvcreate -T vg0/thin_pool -V 300M -L150M -n lvol1

シンプールとシン論理ボリュームを一覧表示する

シンプールもシン論理ボリュームも特殊な種類の論理ボリュームであり、そのため lvdisplay コマンドによって表示されます。lvscan コマンドもこれらの論理ボリュームを検出するでしょう。

シンプールを拡張する

Warning
LVM2 2.02.89 の時点で、シンプールのメタデータサイズは拡張することができず、作成時の値で固定されます

シンでない論理ボリュームと同様に、シンプールは lvextend を使用して拡張されます。例えば:

root #lvextend -L500M vg0/thin_pool

シン論理ボリュームを拡張する

シン論理ボリュームは、通常の論理ボリュームと同様に拡張されます:

root #lvextend -L1G vg0/lvol1

lvextend コマンドでは、作成の際に使用した「仮想サイズ」のオプションと同様ではなく、-L オプション (または、エクステント数を使う場合は -l) を使うことに注意してください。

シンプールを縮小する

現時点で、LVM はシンプールのサイズを縮小させることはできません。LVM のバグ 812731 を確認してください。

シン論理ボリュームを縮小する

シン論理ボリュームは、通常の論理ボリュームと同様に縮小されます。

例えば:

root #lvreduce -L300M vg0/lvol1l

lvreduce コマンドでは、作成の際に使用した「仮想サイズ」のオプションと同様ではなく、-L オプション (または、エクステント数を使う場合は -l) を使うことに注意してください。

シンプールを削除する

シンプールは、その中のすべてのシン論理ボリュームが削除されるまで、削除することができません。

シンプールがシン論理ボリュームをひとつも提供していないなら、lvremove コマンドを使って削除することができます:

root #lvremove vg0/thin_pool

LVM2 スナップショットとシンスナップショット

スナップショットは、他の論理ボリュームのコピーとして振る舞う論理ボリュームです。スナップショットはそれが作成された時点でのオリジナルの論理ボリュームの状態として見ることができます。

Warning
論理スナップショットボリュームは、元のボリュームと同じファイルシステム LABELUUID を持つので、/etc/fstab ファイルまたは initramfs 上で、これらのファイルシステムを指すために LABEL= または UUID= 記法を使用したエントリが含まれないようにしてください。そうしないと、(意図した) オリジナルの論理ボリュームの代わりに、スナップショットがマウントされてしまうかもしれません。

スナップショット論理ボリュームを作成する

スナップショット論理ボリュームは、lvcreate-s オプションを使用することで作成されます。スナップショット論理ボリュームにも記憶域が割り付けられ、与えられます。LVM はオリジナルの論理ボリュームに対して行われた変更をすべて「記録」し、これらの変更をスナップショットのために割り付けられた記憶域に保管します。スナップショットの状態が問い合わせられたとき、LVM はオリジナルの論理ボリュームを元にして、すべての記録された変更を確認し、変更を「アンドゥ」した結果をユーザに提示します。

したがって、スナップショット論理ボリュームはオリジナルの論理ボリュームへ変更が行われるのに応じて「成長」します。スナップショットに割り付けられた記憶域が完全に使用されると、スナップショットは自動的にシステムから削除されます。

root #lvcreate -l 10%VG -s -n 20140412_lvol1 /dev/vg0/lvol1

上の例は、ボリュームグループ vg0 内の論理ボリューム lvol1 を元にして、20140412_lvol1 という名前のスナップショット論理ボリュームを作成します。スナップショット論理ボリュームは、ボリュームグループに割り付けられた容量 (実際にはエクステント) の 10% を使用します。

スナップショット論理ボリュームにアクセスする

スナップショット論理ボリュームは通常の論理ボリュームと同じようにマウントすることができます。スナップショットに対して行える操作は読み込みのみに制限されません。スナップショットを変更することもできるので、「実運用」用のファイルシステムに変更を加える前に変更をテストするためにスナップショットを使用することができます。

スナップショット論理ボリュームが存在している間は、通常のオリジナルの論理ボリュームはサイズ縮小または削除を行うことができません。

LVM シンスナップショット

Note
シンスナップショットは、シン論理ボリュームのシンプールに対してのみ取ることができます。シンデバイスマッパーターゲットは、読み取り専用のシンでない論理ボリュームのシンスナップショットに対応していますが、LVM2 はこれに対応していません。しかしながら、シン論理ボリュームに対する通常の (シンでない) スナップショット論理ボリュームを作成することは可能です。

シンスナップショットを作成するには、lvcreate コマンドを -s とともに利用します。サイズの宣言を渡す必要はありません:

root #lvcreate -s -n 20140413_lvol1 /dev/vg0/lvol1

シン論理ボリュームスナップショットは、オリジナルのシン論理ボリュームと同じサイズを持ち、他のシン論理ボリュームと同様に物理割り付けを行いません。

Important
-l または -L を指定すると、それでもスナップショットは作成されますが、出来上がるスナップショットはシンスナップショットではなく、通常のスナップショットになってしまうでしょう。

スナップショットのスナップショットを取ることもできます:

root #lvcreate -s -n 1_20140413_lvol1 /dev/vg0/20140413_lvol1

シンスナップショットには通常のスナップショットに対するいくつかの利点があります。第一に、シンスナップショットは一度作成されると、オリジナルの論理ボリュームから独立したものになります。オリジナルの論理ボリュームは、スナップショットに影響を与えることなく縮小したり削除したりできます。第二に、シンスナップショットを再帰的に (スナップショットのスナップショットを) 作成する場合、通常の再帰 LVM スナップショットで発生する "連鎖" オーバーヘッドがなく、効率的に作成することができます。

スナップショットの状態にロールバックする

論理ボリュームをスナップショットの版にロールバックするには、次のコマンドを使用してください:

root #lvconvert --merge /dev/vg0/20140413_lvol1

ボリュームのサイズにもよりますが、これには数分かかることがあります。親の論理ボリュームがオフラインになったときに初めてロールバックが発生することに注意してください。そのため再起動が必要になるかもしれません。

Important
スナップショットは消失し、この変更を元に戻すことはできません

シンスナップショットをロールバックする

シンボリュームでは、lvconvert --merge は動作しません。代わりに、オリジナルの論理ボリュームを削除して、スナップショットの名前を変更してください:

root #umount /dev/vg0/lvol1
root #lvremove /dev/vg0/lvol1
root #lvrename vg0/20140413_lvol1 lvol1

様々なストレージ割り付け方法

LVM は様々なストレージの割り付け方法に対応しています:

  • リニアボリューム (これがデフォルトです);
  • ミラー化ボリューム (アクティブ/スタンバイ構成に近い);
  • ストライピング (RAID0);
  • ミラー化ボリューム (RAID1 - アクティブ/アクティブ構成に近い);
  • パリティ付きストライピング (RAID4 および RAID5);
  • ダブルパリティ付きストライピング (RAID6);
  • ストライピングおよびミラーリング (RAID10).

リニアボリューム

リニアボリュームは最もよく使われる LVM ボリュームの種類です。LVM は論理ボリュームを可能な限り物理的に連続して割り付けようとします。論理ボリューム全体を収められる大きさの物理ボリュームがある場合は、LVM はそこに論理ボリュームを割り付け、そうでない場合は可能な限り少ない断片に分けることになります。

先に紹介したボリュームグループと論理ボリュームを作成するコマンドは、リニアボリュームを作成します。

リニアボリュームには特別な前提条件が無いため、最も利用しやすく、自在にリサイズや移動を行うことができます。論理ボリュームが複数の物理ボリュームにまたがって割り付けられている場合、物理ボリュームのどれかひとつでも利用できなくなると、その論理ボリュームはもはや開始させることができず、利用できなくなるでしょう。

ミラー化ボリューム

LVM はミラー化されたボリュームに対応しており、ドライブ障害発生時の耐障害性を提供します。RAID1 とは違い、パフォーマンス上の利点はありません。すべての読み込みと書き込みはミラーの一方に行われます。

ミラーの状態を追跡するために、LVM はログを取る必要があります。このログは、ミラー化論理ボリュームのいずれも含まない物理ボリューム上に配置するのが推奨されます (むしろ必須であることも多いです)。ミラーのために利用できるログは 3 種類あります:

  1. Disk is the default log type. All changes made are logged into extra metadata extents, which LVM manages. If a device fails, then the changes are kept in the log until the mirror can be restored again.
  2. Mirror logs are disk logs that are themselves mirrored.
  3. Core mirror logs record the state of the mirror in memory only. LVM will have to rebuild the mirror every time it is activated. This type is useful for temporary mirrors.

To create a logical volume with a single mirror, pass the -m 1 argument (to select standard mirroring) with optionally --mirrorlog to select a particular log type:

root #lvcreate -m 1 --mirrorlog mirror -l 40%VG --nosync -n lvol1 vg0

The -m 1 tells LVM to create one (additional) mirror, so requiring 2 physical volumes. The --nosync option is an optimization - without it LVM will try synchronize the mirror by copying empty sectors from one logical volume to another.

It is possible to create a mirror of an existing logical volume:

root #lvconvert -m 1 -b vg0/lvol1

The -b option does the conversion in the background as this can take quite a while.

To remove a mirror, set the number of mirrors (back) to 0:

root #lvconvert -m0 vg0/lvol1

If part of the mirror is unavailable (usually because the disk containing the physical volume has failed), the volume group will need to be brought up in degraded mode:

root #vgchange -ay --partial vg0

On the first write, LVM will notice the mirror is broken. The default policy ("remove") is to automatically reduce/break the mirror according to the number of pieces available. A 3-way mirror with a missing physical volume will be reduced to 2-way mirror; a 2-way mirror will be reduced to a regular linear volume. If the failure is only transient, and the missing physical volume returns after LVM has broken the mirror, the mirrored logical volume will need to be recreated on it.

To recover the mirror, the failed physical volume needs to be removed from the volume group, and a replacement physical volume needs to be added (or if the volume group has a free physical volume, it can be created on that one). Then the mirror can be recreated with lvconvert at which point the old physical volume can be removed from the volume group:

root #vgextend vg0 /dev/sdc1
root #lvconvert -b -m 1 --mirrorlog disk vg0/lvol1
root #vgreduce --removemissing vg0

It is possible to have LVM recreate the mirror with free extents on a different physical volume if one side fails. To accomplish that, set mirror_image_fault_policy to allocate in lvm.conf.

シンミラー

It is not (yet) possible to create a mirrored thin pool or thin volume. It is possible to create a mirrored thin pool by creating a normal mirrored logical volume and then converting the logical volume to a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Warning
LVM 2.02.98 or above is required for this to work properly. Prior versions are either not capable or will segfault and corrupt the volume group. Also, conversion of a mirror into a thin pool destroys all existing data in the mirror!
root #lvcreate -m 1 --mirrorlog mirrored -l40%VG -n thin_pool vg0
root #lvcreate -m 1 --mirrorlog mirrored -L4MB -n thin_meta vg0
root #lvconvert --thinpool vg0/thin_pool --poolmetadata vg0/thin_meta

ストライピング (RAID0)

Instead of a linear volume, where multiple contiguous physical volumes are appended, it possible to create a striped or RAID0 volume for better performance. This will alternate storage allocations across the available physical volumes.

To create a striped volume over three physical volumes:

root #lvcreate -i 3 -l 20%VG -n lvol1_stripe vg0
Using default stripesize 64.00 KiB

The -i option indicates over how many physical volumes the striping should be done.

It is possible to mirror a stripe set. The -i and -m options can be combined to create a striped mirror:

root #lvcreate -i 2 -m 1 -l 10%VG vg0

This creates a 2 physical volume stripe set and mirrors it on 2 different physical volumes, for a total of 4 physical volumes. An existing stripe set can be mirrored with lvconvert.

A thin pool can be striped like any other logical volume. All the thin volumes created from the pool inherit that settings - do not specify it manually when creating a thin volume.

It is not possible to stripe an existing volume, nor reshape the stripes across more/less physical volumes, nor to convert to a different RAID level/linear volume. A stripe set can be mirrored. It is possible to extend a stripe set across additional physical volumes, but they must be added in multiples of the original stripe set (which will effectively linearly append a new stripe set).

ミラーリング (RAID1)

Unlike RAID0, which is striping, RAID1 is mirroring, but implemented differently than the original LVM mirror. Under RAID1, reads are spread out across physical volumes, improving performance. RAID1 mirror failures do not cause I/O to block because LVM does not need to break it on write.

Any place where an LVM mirror could be used, a RAID1 mirror can be used in its place. It is possible to have LVM create RAID1 mirrors instead of regular mirrors implicitly by setting mirror_segtype_default to raid1 in lvm.conf.

Warning
LVM RAID1 mirroring is not supported by GRUB before version 2.02. Ensure the latest version is installed with grub-install or the system may become unbootable if the grub files are contained in the LVM RAID1.

To create a logical volume with a single mirror:

root #lvcreate -m 1 --type raid1 -l 40%VG --nosync -n lvm_raid1 vg0

Note the difference for creating a mirror: There is no mirrorlog specified, because RAID1 logical volumes do not have an explicit mirror log - it built-in to the logical volume.

It is possible to convert an existing logical volume to RAID1:

root #lvconvert -m 1 --type raid1 -b vg0/lvol1

To remove a RAID1 mirror, set the number of mirrors to 0:

root #lvconvert -m0 vg0/lvm_raid1

If part of the RAID1 is unavailable (usually because the disk containing the physical volume has failed), the volume group will need to be brought up in degraded mode:

root #vgchange -ay --partial vg0

Unlike an LVM mirror, writing does NOT break the mirroring. If the failure is only transient, and the missing physical volume returns, LVM will resync the mirror by copying cover the out-of-date segments instead of the entire logical volume. If the failure is permanent, then the failed physical volume needs to be removed from the volume group, and a replacement physical volume needs to be added (or if the volume group has a free physical volume, it can be created on a different PV). The mirror can then be repaired with lvconvert, and the old physical volume can be removed from the volume group:

root #vgextend vg0 /dev/sdc1
root #lvconvert --repair -b vg0/lvm_raid1
root #vgreduce --removemissing vg0

シン RAID1

It is not (yet) possible to create a RAID1 thin pool or thin volume. It is possible to create a RAID1 thin pool by creating a normal mirrored logical volume and then converting the logical volume to a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will then merge them into a single logical volume.

Warning
LVM 2.02.98 or above is required for this to work properly. Prior versions are either not capable or will segfault and corrupt the VG. Also, conversion of a RAID1 into a thin pool destroys all existing data in the mirror!
root #lvcreate -m 1 --type raid1 -l40%VG -n thin_pool vg0
root #lvcreate -m 1 --type raid1 -L4MB -n thin_meta vg0
root #lvconvert --thinpool vg0/thin_pool --poolmetadata vg00/thin_meta

パリティ付きストライピング (RAID4 および RAID5)

Note
パリティ付きストライピングは少なくとも 3 個の物理ボリュームを必要とします。

RAID0 is not fault-tolerant - if any of the physical volumes fail then the logical volume is unusable. By adding a parity stripe to RAID0 the logical volume can still function if a physical volume is missing. A new physical volume can then be added to restore fault tolerance.

Stripsets with parity come in 2 flavors: RAID4 and RAID5. Under RAID4, all the parity stripes are stored on the same physical volume. This can become a bottleneck because all writes hit that physical volume, and it gets worse the more physical volumes are in the array. With RAID5, the parity data is distributed evenly across the physical volumes so none of them become a bottleneck. For that reason, RAID4 is rare and is considered obsolete/historical. In practice, all stripesets with parity are RAID5.

root #lvcreate --type raid5 -l 20%VG -i 2 -n lvm_raid5 vg0

Only the data physical volumes are specified with -i, LVM adds one to it automatically for the parity. So for a 3 physical volume RAID5, -i 2 is passed on and not -i 3.

When a physical volume fails, then the volume group will need to be brought up in degraded mode:

root #vgchange -ay --partial vg0

The volume will work normally at this point, however this degrades the array to RAID0 until a replacement physical volume is added. Performance is unlikely to be affected while the array is degraded - although it does need to recompute its missing data via parity, it only requires simple XOR for the parity block with the remaining data. The overhead is negligible compared to the disk I/O.

RAID5 を修復するには:

root #lvconvert --repair vg0/lvm_raid5
root #vgreduce --removemissing vg0

It is possible to replace a still working physical volume in RAID5 as well:

root #lvconvert --replace /dev/sdb1 vg0/lvm_raid5
root #vgreduce vg0 /dev/sdb1

The same restrictions of stripe sets apply to stripe sets with parity as well: it is not possible to enable striping with parity on an existing volume, nor reshape the stripes with parity across more/less physical volumes, nor to convert to a different RAID level/linear volume. A stripe set with parity can be mirrored. It is possible to extend a stripe set with parity across additional physical volumes, but they must be added in multiples of the original stripe set with parity (which will effectively linearly append a new stripe set with parity).

シン RAID5 論理ボリューム

It is not (yet) possible to create stripe set with parity (RAID5) thin pools or thin logical volumes. It is possible to create a RAID5 thin pool by creating a normal RAID5 logical volume and then converting the logical volume into a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Warning
LVM 2.02.98 or above is required for this to work properly. Prior versions are either not capable or will segfault and corrupt the VG. Also, coversion of a RAID5 LV into a thin pool destroys all existing data in the LV!
root #lvcreate --type raid5 -i 2 -l20%VG -n thin_pool vg0
root #lvcreate --type raid5 -i 2 -L4MB -n thin_meta vg0
root #lvconvert --thinpool vg0/thin_pool --poolmetadata vg00/thin_meta

ダブルパリティ付きストライピング (RAID6)

Note
RAID6 は少なくとも 5 個の物理ボリュームを必要とします。

RAID6 is similar to RAID5, however RAID6 can survive up to two physical volume failures, thus offering more fault tolerance than RAID5 at the expense of extra physical volumes.

root #lvcreate --type raid6 -l 20%VG -i 3 -n lvm_raid6 vg00

Like RAID5, the -i option is used to specify the number of physical volumes to stripe, excluding the 2 physical volumes for parity. So for a 5 physical volume RAID6, pass on -i 3 and not -i 5.

RAID6 の回復は RAID5 と同じです。

Note
Unlike RAID5 where parity block is cheap to recompute vs disk I/O, this is only half true in RAID6. RAID6 uses 2 parity stripes: One stripe is computed the same way as RAID5 (simple XOR). The second parity stripe is much harder to compute - see [https://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf

シン RAID6 論理ボリューム

It is not (yet) possible to create a RAID6 thin pool or thin volumes. It is possible to create a RAID6 thin pool by creating a normal RAID6 logical volume and then converting the logical volume into a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Warning
LVM 2.02.98 or above is required for this to work properly. Prior versions are either not capable or will segfault and corrupt the VG. Also, conversion of a RAID6 LV into a thin pool destroys all existing data in the LV!
root #lvcreate --type raid6 -i 2 -l20%VG -n thin_pool vg0
root #lvcreate --type raid6 -i 2 -L4MB -n thin_meta vg0
root #lvconvert --thinpool vg0/thin_pool --poolmetadata vg0/thin_meta

LVM RAID10

Note
RAID10 requires at least 4 physical volumes. Also LVM syntax requires the number of physical volumes be multiple of the numbers stripes and mirror, even though RAID10 format does not

RAID10 is a combination of RAID0 and RAID1. It is more powerful than RAID0+RAID1 as the mirroring is done at the stripe level instead of the logical volume level, and therefore the layout doesn't need to be symmetric. A RAID10 volume can tolerate at least a single missing physical volume, and possibly more.

Note
LVM currently limits RAID10 to a single mirror.
root #lvcreate --type raid10 -l 1020 -i 2 -m 1 --nosync -n lvm_raid10 vg0

Both the -i and -m options are specified: -i is the number of stripes and -m is the number of mirrors. Two stripes and 1 mirror requires 4 physical volumes.

シン RAID10

It is not (yet) possible to create a RAID10 thin pool or thin volumes. It is possible to create a RAID10 thin pool by creating a normal RAID10 logical volume and then converting the logical volume into a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Warning
Conversion of a RAID10 logical volume into a thin pool destroys all existing data in the logical volume!
root #lvcreate -i 2 -m 1 --type raid10 -l 1012 -n thin_pool vg0
root #lvcreate -i 2 -m 1 --type raid10 -l 6 -n thin_meta vg0
root #lvconvert --thinpool vg0/thin_pool --poolmetadata vg0/thin_meta

Experimenting with LVM

実際のストレージデバイスを使用せずに LVM で実験することができます。これを実現するために、ループバックデバイスを作成します。

まずは、ループバックモジュールがロードされているか確認してください。

root #modprobe -r loop && modprobe loop max_part=63
Note
ループバックサポートがカーネルに組み込まれている場合は、ブートオプションとして loop.max_part=63 を使用してください。

次に、デバイスのスキャンに udev を使用しないように LVM を設定してください:

FILE /etc/lvm/lvm.confLVM コンフィグで udev を無効化する
obtain_device_list_from_udev = 0
Important
これはテストのみを目的としたものです。実際のデバイスを取り扱うときは udev を使ったほうが速いので、忘れずに設定を戻してください!

Create some image files which will become the storage devices. The next example uses five files for a total of about ~10GB of real hard drive space:

root #mkdir /var/lib/lvm_img
root #dd if=/dev/null of=/var/lib/lvm_img/lvm0.img bs=1024 seek=2097152
root #dd if=/dev/null of=/var/lib/lvm_img/lvm1.img bs=1024 seek=2097152
root #dd if=/dev/null of=/var/lib/lvm_img/lvm2.img bs=1024 seek=2097152
root #dd if=/dev/null of=/var/lib/lvm_img/lvm3.img bs=1024 seek=2097152
root #dd if=/dev/null of=/var/lib/lvm_img/lvm4.img bs=1024 seek=2097152

Check which loopback devices are available:

root #losetup -a

Assuming all loopback devices are available, next create the devices:

root #losetup /dev/loop0 /var/lib/lvm_img/lvm0.img
root #losetup /dev/loop1 /var/lib/lvm_img/lvm1.img
root #losetup /dev/loop2 /var/lib/lvm_img/lvm2.img
root #losetup /dev/loop3 /var/lib/lvm_img/lvm3.img
root #losetup /dev/loop4 /var/lib/lvm_img/lvm4.img

The /dev/loop[0-4] devices are now available to use as any other hard drive in the system (and thus be perfect for physical volumes).

Note
On the next reboot, all the loopback devices will be released and the folder /var/lib/lvm_img can be deleted.

トラブルシューティング

LVM は、既にいくつかのレベルの冗長性を提供するいくつかの機能です。しかし、状況が失われる物理ボリュームまたは論理ボリュームを復元することがあります。

vgcfgrestore ユーティリティ

By default, on any change to a LVM physical volume, volume group, or logical volume, LVM2 create a backup file of the metadata in /etc/lvm/archive. These files can be used to recover from an accidental change (like deleting the wrong logical volume). LVM also keeps a backup copy of the most recent metadata in /etc/lvm/backup. These can be used to restore metadata to a replacement disk, or repair corrupted metadata.

To see what states of the volume group are available to be restored (partial output to improve readability):

root #vgcfgrestore --list vg00
  File:		/etc/lvm/archive/vg0_00042-302371184.vg
  VG name:    	vg0
  Description:	Created *before* executing 'lvremove vg0/lvm_raid1'
  Backup Time:	Sat Jul 13 01:41:32 201

Recovering an accidentally deleted logical volume

Assuming the logical volume lvm_raid1 was accidentally removed from volume group vg0, it is possible to recover it as follows:

root #vgcfgrestore -f /etc/lvm/archive/vg0_00042-302371184.vg vg0
Important
vgcfgrestore only restores LVM metadata, not the data inside the logical volume. However pvremove, vgremove, and lvremove only wipe metadata, leaving any data intact. If issue_discards is set in /etc/lvm/lvm.conf though, then these command are destructive to data.

Replacing a failed physical volume

It possible to do a true "replace" and recreate the metadata on the new physical volume to be the same as the old physical volume:

root #vgdisplay --partial --verbose
  --- Physical volumes ---
  PV Name               /dev/loop0     
  PV UUID               iLdp2U-GX3X-W2PY-aSlX-AVE9-7zVC-Cjr5VU
  PV Status             allocatable
  Total PE / Free PE    511 / 102
  
  PV Name               unknown device     
  PV UUID               T7bUjc-PYoO-bMqI-53vh-uxOV-xHYv-0VejBY
  PV Status             allocatable
  Total PE / Free PE    511 / 102

The important line here is the UUID "unknown device".

root #pvcreate --uuid T7bUjc-PYoO-bMqI-53vh-uxOV-xHYv-0VejBY --restorefile /etc/lvm/backup/vg0 /dev/loop1
  Couldn't find device with uuid T7bUjc-PYoO-bMqI-53vh-uxOV-xHYv-0VejBY.
  Physical volume "/dev/loop1" successfully created

This recreates the physical volume metadata, but not the missing logical volume or volume group data on the physical volume.

root #vgcfgrestore -f /etc/lvm/backup/vg0 vg0
  Restored volume group vg0

This now reconstructs all the missing metadata on the physical volume, including the logical volume and volume group data. However it doesn't restore the data, so the mirror is out of sync.

root #vgchange -ay vg0
  device-mapper: reload ioctl on  failed: Invalid argument
  1 logical volume(s) in volume group "vg0" now active
root #lvchange --resync vg0/lvm_raid1
Do you really want to deactivate logical volume lvm_raid1 to resync it? [y/n]: y

This will resync the mirror. This works with RAID 4,5 and 6 as well.

Deactivating a logical volume

It is possible to deactivate a logical volume with the following command:

root #umount /dev/vg0/lvol1
root #lvchange -a n /dev/vg0/lvol1

It is not possible to mount the logical volume anywhere before it gets reactivated:

root #lvchange -a y /dev/vg0/lvol1

参考

外部の情報