「LVM」の版間の差分
(→例: 仮想プライベートサーバを立てる: 翻訳) |
|||
| 574行目: | 574行目: | ||
=== 例: ゼロダウンタイムでストレージをアップグレードする === |
=== 例: ゼロダウンタイムでストレージをアップグレードする === |
||
| + | VPS のホスティング以外にもシンプロビジョニングの活用法は存在します。シンプロビジョニングを使用して、すでにマウントされているファイルシステムをアンマウントすることなく、その実効容量を増やす方法を紹介しましょう。ここでは (再び)、サーバに1台の 930 GiB ハードドライブが搭載されていると仮定します。環境は VPS ホスティングのときと同じですが、シン LV が1つしかなく、LV のサイズはシンプールのサイズよりも遥かに大きいとします。 |
||
| − | There are applications of thin provisioning outside of VPS hosting. Here is how you may use it to grow the effective capacity of an already-mounted file system without having to unmount it. Suppose, again, that the server has a single 930 GiB hard drive. The setup is the same as for VPS hosting, only there is only one thin LV and the LV's size is far larger than the thin pool's size. |
||
# lvcreate -n MyThinLV -V 16T --thinpool MyThinPool MyVolGroup |
# lvcreate -n MyThinLV -V 16T --thinpool MyThinPool MyVolGroup |
||
| + | この追加の仮想領域は、シンプールを拡張することで後に実際のストレージで埋めることができます。 |
||
| − | This extra virtual space can be filled in with actual storage at a later time by extending the thin pool. |
||
| + | しばらくして、ストレージのアップグレードが必要になり、新しいハードドライブ {{ic|/dev/sdc}} がサーバに接続されたとします。シンプールの容量をアップグレードするには、新しいハードドライブを VG に追加します: |
||
| − | Suppose some time later, a storage upgrade is needed, and a new hard drive, {{ic|/dev/sdc}}, is plugged into the server. To upgrade the thin pool's capacity, add the new hard drive to the VG: |
||
# vgextend MyVolGroup /dev/sdc |
# vgextend MyVolGroup /dev/sdc |
||
| + | 次に、シンプールを拡張します: |
||
| − | Now, extend the thin pool: |
||
# lvextend -l +95%FREE MyVolGroup/MyThinPool |
# lvextend -l +95%FREE MyVolGroup/MyThinPool |
||
| + | このシン LV のサイズは 16 TiB なので、最終的にファイルシステムをアンマウントしてサイズ変更するはめになるまでに、さらに 15.09 TiB のハードドライブ領域を追加できます。 |
||
| − | Since this thin LV's size is 16 TiB, you could add another 15.09 TiB of hard drive space before finally having to unmount and resize the file system. |
||
| + | {{Note|アプリケーションが実際に存在する以上の物理ストレージを使用しないようにするために、[[Ext4#予約ブロック|予約ブロック]]や[[ディスククォータ]]を使うべきかもしれません。}} |
||
| − | {{Note|You will probably want to use [[Ext4#Reserved blocks|reserved blocks]] or a [[disk quota]] to prevent applications from attempting to use more physical storage than there actually is.}} |
||
== トラブルシューティング == |
== トラブルシューティング == |
||
2023年1月26日 (木) 20:35時点における版
関連記事
Wikipedia より:
- LVM は Linux カーネルの論理ボリュームマネージャです。ディスクドライブと大容量記憶装置を管理します。
目次
背景
LVM の構成要素
Logical Volume Management は Linux カーネルの device-mapper 機能を利用して、基底のディスクレイアウトから独立したパーティションのシステムを提供します。LVM を使うことでストレージを抽象化し「仮想的なパーティション」を作成して、拡張/縮小を容易にします (ファイルシステムの制限を受ける可能性があります)。
仮想パーティションにより、パーティションディスク上に十分な連続領域が存在するかどうかを心配したり、使用中のディスクに fdisk してしまったり (そして、カーネルが古いパーティションテーブルと新しいほうのどちらを使っているか悩んだり)、他のパーティションを移動してスペースを作らないといけなかったりすることなく、追加と削除ができるようになります。
LVM の基本的構成要素:
- 物理ボリューム (Physical Volume, PV)
- LVM によって利用可能な Unix ブロックデバイスノード。例: ハードディスク、MBR か GPT のパーティション、ループバックファイル、デバイスマッパーデバイス (例: dm-crypt)。PV は LVM のヘッダをホストします。
- ボリュームグループ (Volume Group, VG)
- LV のコンテナとして機能する、PV の集まり。VG から PE を割り当てて LV を構成します。
- 論理ボリューム (Logical Volume, LV)
- VG 内に存在する「仮想/論理パーティション」であり、PE で構成されます。LV は、物理パーティションに似た Unix ブロックデバイスです。例えば、LV はファイルシステムで直接フォーマットできます。
- 物理エクステント (Physical Extent, PE)
- LV に割り当てることのできる、PV 内の最小の連続するエクステント (範囲) です。PE は、任意の LV に割り当てることのできる、PV のパーツだと考えてください。
例:
物理ディスク
ディスク1 (/dev/sda):
┌─────────────────────────────────────┬─────────────────────────────────────┐
│ パーティション1 50 GiB (物理ボリューム) │ パーティション2 80 GiB (物理ボリューム) │
│ /dev/sda1 │ /dev/sda2 │
└─────────────────────────────────────┴─────────────────────────────────────┘
ディスク2 (/dev/sdb):
┌─────────────────────────────────────┐
│ パーティション1 120 GiB (物理ボリューム) │
│ /dev/sdb1 │
└─────────────────────────────────────┘
LVM 論理ボリューム
ボリュームグループ1 (/dev/MyVolGroup/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):
┌─────────────────────────┬─────────────────────────┬──────────────────────────┐
│ 論理ボリューム1 15 GiB │ 論理ボリューム2 35 GiB │ 論理ボリューム3 200 GiB │
│ /dev/MyVolGroup/rootvol │ /dev/MyVolGroup/homevol │ /dev/MyVolGroup/mediavol │
└─────────────────────────┴─────────────────────────┴──────────────────────────┘
利点
LVM には、通常のハードドライブのパーティションをただ使うよりも幅広い柔軟性があります:
- 多数のディスクを一つの大きなディスクとして使えます。
- 複数のディスクにまたがる論理ボリュームを作れます。
- 小さな論理ボリュームを作成し、満杯になったら"動的に"リサイズできます。
- ディスクの順番と関係なく論理ボリュームをリサイズできます。VG における LV の位置に依存しないので、周辺に空き容量を取る必要がありません。
- オンラインで論理・物理ボリュームをリサイズ・作成・削除できます。ボリューム上のファイルシステムもリサイズする必要がありますが、オンラインリサイズをサポートしているファイルシステムもあります (ext4 など)。
- サービスによって使われている LV を、サービスを再起動する必要なく他のディスクへオンラインで移行することができます。
- スナップショットを使うことでファイルシステムのフローズンコピーをバックアップすることができます。サービスを落とす時間を最小限にできます。
- 起動時にキーを複数回入力することなく、個別のボリュームをアンロック (LUKS 上に LVM を作成)。
- 頻繁に使用されるデータをキャッシュする組み込みサポート (lvmcache(7))。
欠点
- システムのセットアップに追加の手順が必要で、やや複雑。(複数の) デーモンを継続的に実行する必要あり。
- デュアルブートする場合、Windows は LVM をサポートしていないことに注意してください。Windows からは LVM パーティションにアクセスできません。サードパーティのソフトウェアによって、特定の種類の LVM セットアップをマウントできる場合があります。[1]
- 物理ボリュームが RAID-1、RAID-5、RAID-6 のどれにもない場合、論理ボリュームが複数の非冗長ディスクにまたがっている (あるいは、拡張されている) と、1つ以上のディスクが失われると1つまたは複数の論理ボリュームが失われる可能性があります。
- 論理ボリュームマネージャによって使用されている領域 (つまり、論理ボリュームのために使用されている物理ボリューム) は (簡単には) 縮小できません。物理エクステントが物理ボリューム上に末尾まで散らばっている場合、Arch Wiki 上で提供されているスクリプトでは物理ボリュームを縮小することはできません。他のオペレーティングシステム (例: Microsoft Windows) とデュアルブートしたい場合、Microsoft Windows のために残される唯一のスペースは、LVM によって使用されない、あるいは物理ボリュームとして使用されない領域となります。
始める
lvm2 パッケージがインストールされていることを確認してください。
LVM ボリュームを initramfs によってアクティブ化しない場合、(lvm2 によって提供される) lvm-monitoring.service を有効化してください。
ボリューム操作
物理ボリューム
作成
/dev/sda1 上に PV (物理ボリューム) を作成するには:
# pvcreate /dev/sda1
PV が作成されたかどうかは、以下のコマンドを使って確認できます:
# pvs
拡張
物理ボリュームのあるデバイスのサイズを増やした後、または減らす前に、pvresize(8) を使って PV を拡大/縮小する必要があります。
パーティションを大きくした後に /dev/sda1 上の PV を拡張するには、以下を実行します:
# pvresize /dev/sda1
これは、自動的にデバイスのサイズを検出し、最大まで PV を拡張します。
縮小
基底となるデバイスを縮小する前に物理ボリュームを縮小するには、パラメータ --setphysicalvolumesize サイズ を先のコマンドに追加してください。例えば:
# pvresize --setphysicalvolumesize 40G /dev/sda1
上記のコマンドは以下のエラーを出力する場合があります:
/dev/sda1: cannot resize to 25599 extents as later ones are allocated. 0 physical volume(s) resized / 1 physical volume(s) not resized
実際 pvresize は、新しい終了位置よりも後にエクステントが割り当てられている場合、PV の縮小を拒否します。十分な空き領域があるならば、前もって pvmove を実行して、そのようなエクステントをボリュームグループ内の別の場所に移動させる必要があります。
物理エクステントを移動させる
空きエクステントをボリュームの末尾に移動させる前に、pvdisplay -v -m を実行して物理セグメントを確認しなければなりません。以下の例では、1つの物理ボリュームが /dev/sdd1 上に存在し、1つのボリュームグループ vg1 と1つの論理ボリューム backup が存在しています。
# pvdisplay -v -m
Finding all volume groups.
Using physical volume(s) on command line.
--- Physical volume ---
PV Name /dev/sdd1
VG Name vg1
PV Size 1.52 TiB / not usable 1.97 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 399669
Free PE 153600
Allocated PE 246069
PV UUID MR9J0X-zQB4-wi3k-EnaV-5ksf-hN1P-Jkm5mW
--- Physical Segments ---
Physical extent 0 to 153600:
FREE
Physical extent 153601 to 307199:
Logical volume /dev/vg1/backup
Logical extents 1 to 153599
Physical extent 307200 to 307200:
FREE
Physical extent 307201 to 399668:
Logical volume /dev/vg1/backup
Logical extents 153601 to 246068
FREE な領域がボリュームを跨いで分かれて存在していることがわかります。物理ボリュームを縮小させるには、まず、すべての使用中セグメントを先頭に移動させなければなりません。
ここで、最初の空きセグメントは 0 から 153600 にあり、153601 の空きエクステントが存在しています。この状態では、このセグメント番号を最後の物理エクステントから最初のエクステントに移動させることができます。なので、コマンドは以下のようになります:
# pvmove --alloc anywhere /dev/sdd1:307201-399668 /dev/sdd1:0-92467
/dev/sdd1: Moved: 0.1 % /dev/sdd1: Moved: 0.2 % ... /dev/sdd1: Moved: 99.9 % /dev/sdd1: Moved: 100.0 %
物理ボリュームのサイズを変更する
すべての空き物理セグメントを最後の物理エクステント上に移動したら、vgdisplay を root 権限で実行して空き PE を確認してください。
そうしたら、先のあのコマンドを再び実行できます:
# pvresize --setphysicalvolumesize サイズ 物理ボリューム
結果を確認しましょう:
# pvs
PV VG Fmt Attr PSize PFree /dev/sdd1 vg1 lvm2 a-- 1t 500g
パーティションのサイズを変更する
最後に、お気に入りのパーティショニングツールを使ってパーティションを縮小させる必要があります。
ボリュームグループ
ボリュームグループを作成する
PV /dev/sdb1 を持つ VG (ボリュームグループ) MyVolGroup を作成するには、以下を実行してください:
# vgcreate MyVolGroup /dev/sdb1
以下のコマンドを使うことで VG MyVolGroup が作成されたことを確認できます:
# vgs
VG の作成時に以下のようにすることで複数の PV をバインドすることができます:
# vgcreate MyVolGroup /dev/sdb1 /dev/sdb2
ボリュームグループをアクティブ化する
# vgchange -a y MyVolGroup
デフォルトでは、これにより該当するボリュームグループが再アクティブ化されます。例えば、仮にミラーでドライブ障害が発生し、そのドライブを交換したとすると、(1) pvcreate、(2) vgextend、(3) vgreduce --removemissing --force を実行するでしょう。
ボリュームグループを修復する
この例での破損したミラーアレイの再ビルドプロセスを開始するには、以下を実行します:
# lvconvert --repair /dev/MyVolGroup/mirror
以下で再ビルドプロセスをモニタリングできます (Cpy%Sync 列の出力):
# lvs -a -o +devices
ボリュームグループを非アクティブ化する
以下を実行してください:
# vgchange -a n MyVolGroup
これは、ボリュームグループを非アクティブ化し、その VG を格納しているコンテナをアンマウントできるようにします。
ボリュームグループの名前を変更する
既存のボリュームグループの名前を変更するには vgrename(8) コマンドを使用してください。
次のいずれかのコマンドにより、既存のボリュームグループ MyVolGroup を my_volume_group に名称変更します:
# vgrename /dev/MyVolGroup /dev/my_volume_group
# vgrename MyVolGroup my_volume_group
名前を変更したボリュームグループを参照している設定ファイル (例: /etc/fstab、/etc/crypttab) をすべてアップデートすることを忘れないでください。
ボリュームグループに物理ボリュームを追加する
まず、使用したいブロックデバイス上に新しい物理ボリュームを作成し、ボリュームグループを拡張します:
# pvcreate /dev/sdb1 # vgextend MyVolGroup /dev/sdb1
これにより、ボリュームグループ上の物理エクステントの合計数が増加し、論理ボリュームによって割り当てられることが可能です。
ボリュームグループからパーティションを削除する
論理ボリュームがパーティション上に存在している場合、まずその論理ボリュームを削除してください。
そのパーティション上にあるすべてのデータを他のパーティションに移動する必要があります。幸い、LVM ではこれを簡単に行えます:
# pvmove /dev/sdb1
特定の物理ボリューム上にデータを移したい場合は、pvmove の第2引数でそれを指定してください:
# pvmove /dev/sdb1 /dev/sdf1
次に、物理ボリュームをボリュームグループから削除する必要があります:
# vgreduce MyVolGroup /dev/sdb1
または、空の物理ボリュームをすべて削除します:
# vgreduce --all MyVolGroup
例: 削除されたか障害が発生しているため見つけることのできない、グループ内の不良ディスクがある場合:
# vgreduce --removemissing --force MyVolGroup
最後に、そのパーティションを他の目的のために使用したい場合で、かつ LVM がそのパーティションを物理ボリュームであると認識させたくない場合:
# pvremove /dev/sdb1
論理ボリューム
論理ボリュームを作成する
ボリュームグループ MyVolGroup に容量 300 GiB の論理ボリューム homevol を作成するには、以下を実行してください:
# lvcreate -L 300G MyVolGroup -n homevol
あるいは、ボリュームグループ MyVolGroup に論理ボリューム homevol を、容量の残りすべてを使って作成するには、次を実行してください:
# lvcreate -l 100%FREE MyVolGroup -n homevol
新しい LV が /dev/MyVolGroup/homevol として現れます。これで、LV を適切なファイルシステムでフォーマットできます。
以下のコマンドで、LV が作成されたことを確認できます:
# lvs
論理ボリュームの名前を変更する
既存の論理ボリュームの名前を変更するには、lvrename(8) コマンドを使用してください。
次のいずれかのコマンドにより、ボリュームグループ MyVolGroup 内の論理ボリューム old_vol を new_vol に名称変更します:
# lvrename /dev/MyVolGroup/old_vol /dev/MyVolGroup/new_vol
# lvrename MyVolGroup old_vol new_vol
名前を変更した論理ボリュームを参照している設定ファイル (例: /etc/fstab、/etc/crypttab) をすべてアップデートすることを忘れないでください。
論理ボリュームとファイルシステムのサイズを一度に変更する
MyVolGroup 内の論理ボリューム mediavol を 10 GiB だけ増やし、ファイルシステムも 同時に リサイズします:
# lvresize -L +10G --resizefs MyVolGroup/mediavol
MyVolGroup 内の論理ボリューム mediavol のサイズを 15 GiB に設定し、ファイルシステムも 同時に リサイズします:
# lvresize -L 15G --resizefs MyVolGroup/mediavol
ボリュームグループ上の空き領域をすべて埋めたい場合、次のコマンドを使用してください:
# lvresize -l +100%FREE --resizefs MyVolGroup/mediavol
更に詳細なオプションは lvresize(8) を参照してください。
論理ボリュームとファイルシステムのサイズを別々に変更する
fsadm(8) によってサポートされていないファイルシステムの場合、論理ボリュームを縮小する前、または拡張した後に、適切なユーティリティを使ってそのファイルシステムをリサイズする必要があります。
ファイルシステムに触れずに、ボリュームグループ MyVolGroup 内の論理ボリューム mediavol を 2 GiB だけ増やすには:
# lvresize -L +2G MyVolGroup/mediavol
そして、ファイルシステム (この例では ext4) を論理ボリュームの最大サイズまで拡張してください:
# resize2fs /dev/MyVolGroup/mediavol
MyVolGroup 内の論理ボリューム mediavol のサイズを 500 MiB だけ減らすには、まず最終的なファイルシステムサイズを計算し、ファイルシステム (この例では ext4) をその新しいサイズに縮小します:。
# resize2fs /dev/MyVolGroup/mediavol NewSize
ファイルシステムが縮小したら、論理ボリュームのサイズも縮小してください:
# lvresize -L -500M MyVolGroup/mediavol
ext2、ext3、ext4 ファイルシステムの場合の正確な論理ボリュームサイズを計算するには、このシンプルな計算式をしようしてください: LVM_EXTENTS = FS_BLOCKS × FS_BLOCKSIZE ÷ LVM_EXTENTSIZE。
# tune2fs -l /dev/MyVolGroup/mediavol | grep Block
Block count: 102400000 Block size: 4096 Blocks per group: 32768
# vgdisplay MyVolGroup | grep "PE Size"
PE Size 4.00 MiB
102400000 blocks × 4096 bytes/block ÷ 4 MiB/extent = 100000 extents
--resizefs を渡せば、正しいことを確認できます。
# lvreduce -l 100000 --resizefs /dev/MyVolGroup/mediavol
... The filesystem is already 102400000 (4k) blocks long. Nothing to do! ... Logical volume sysvg/root successfully resized.
更に詳細なオプションは lvresize(8) を参照してください。
論理ボリュームを削除する
まず、削除したい論理ボリュームの名前を調べてください。以下のコマンドですべての論理ボリュームのリストを得られます:
# lvs
次に、選択した論理ボリュームのマウントポイントを探してください:
$ lsblk
そうしたら、論理ボリューム上のファイルシステムをアンマウントしてください:
# umount /マウントポイント
最後に、論理ボリュームを削除してください:
# lvremove ボリュームグループ/論理ボリューム
例えば:
# lvremove MyVolGroup/homevol
y を押して、確定してください。
削除した論理ボリュームを参照しているすべての設定ファイル (例: /etc/fstab、/etc/crypttab) を更新することを忘れないでください。
lvs を root として実行することで、論理ボリュームが削除されたことを確認できます (このセクションの最初のステップを参照)。
スナップショット
LVM は CoW (コピーオンライト, Copy-on-Write) スナップショットをサポートしています。CoW スナップショットは初めはオリジナルデータを参照します。データブロックが上書きされた時、オリジナルコピーはそのまま残り、新しいブロックはディスク上の別の場所に書き込まれます。これには、いくつかの望ましい特性があります:
- データをコピーしない (ディスク上の場所を指すポインタのより小さいリストだけです) ため、スナップショットの作成が高速です。
- スナップショットは、新しいデータブロック (加えて、新しいブロックを指すポインタのための無視できるほど小さい領域) を保持するのに十分な空き領域しか必要としません。例えば、(オリジナルとスナップショットの両方に) 2 GiB だけ書き込んだ 35 GiB のデータのスナップショットは 2 GiB の空き領域しか必要としません。
LVM スナップショットはブロックレベルです。LVM スナップショットは、LVM ツールを扱う場合を除いて、オリジナルと明らかな関連を持たない、新しいブロックデバイスを作成します。なので、オリジナルコピー内でファイルを削除しても、スナップショット内の領域は開放されません。ファイルシステムレベルのスナップショットが必要である場合は、btrfs や ZFS、bcache が必要です。
設定
スナップショットの論理ボリュームは通常の論理ボリュームと同じように作成します。
# lvcreate --size 100M --snapshot --name snap01vol /dev/MyVolGroup/lvol
上記のボリュームでは、スナップショットボリュームが一杯になるまで 100 MiB のデータを変更を加えることができます。
次のコマンドを使うことで、変更が加えられた lvol 論理ボリュームを、snap01vol スナップショットが作成された時の状態まで戻すことができます:
# lvconvert --merge /dev/MyVolGroup/snap01vol
オリジナルの論理ボリュームが使用中の場合は、次回のブート時にマージサれます (LiveCD からマージすることもできます)。
また、複数のスナップショットを作成して、それぞれを自由にオリジナルの論理ボリュームにマージすることも可能です。
バックアップ
スナップショットは、バックアップの作成のためにファイルシステムの凍結されたコピーを提供します。例えば、2時間かかったバックアップは、パーティションを直接バックアップするよりも、ファイルシステムのより一貫性のあるイメージを提供します。
dd や tar でスナップショットをマウントしたりバックアップしたりできます。dd によって作成されたバックアップファイルのサイズは、対象のスナップショットボリューム上に存在するファイルの総サイズとなります。(バックアップから) 復元するには、スナップショットを作成し、それをマウントし、そこへバックアップを書き込むか展開してください。その後、そのスナップショットを origin にマージしてください。
バックアップとロールバックのために、システム起動時にルートファイルシステムのクリーンなスナップショットを自動的に作成する方法については、LVM によるルートファイルシステムのスナップショット を参照してください。
暗号化
LUKS と LVM の組み合わせの可能なスキームについては、dm-crypt/システム全体の暗号化#LUKS on LVM と dm-crypt/システム全体の暗号化#LVM on LUKS を参照してください。
キャッシュ
lvmcache(7) より:
- キャッシュ論理ボリュームタイプは小さくて高速な LV を使うことで巨大で鈍重な LV のパフォーマンスを改善します。頻繁に使用されるブロックを高速な LV に保存することで高速化します。LVM は小さくて高速な LV のことをキャッシュプール LV と呼び、巨大で鈍重な LV のことをオリジン LV と呼びます。dm-cache (カーネルドライバー) の要件を満たすため、LVM はキャッシュプール LV をさらに2つのデバイスに分割します。キャッシュデータ LV とキャッシュメタデータ LV です。キャッシュデータ LV にはオリジン LV のデータブロックのコピーが保存されます。キャッシュメタデータ LV にはどこにデータブロックが保存されるかを示す情報が格納されます (例: オリジン LV にあるのかあるいはキャッシュデータ LV にあるのか)。最速かつ最強のキャッシュ論理ボリュームを作成しようと考えている場合はこれらの LV をよく知る必要があります。これらの LV は全て同一の VG に入っていなければなりません。
キャッシュを作成する
高速なディスク (/dev/fastdisk) を PV に変換し、既存の VG (MyVolGroup) に追加します:
# vgextend MyVolGroup /dev/fastdisk
/dev/fastdisk 上に自動メタデータのあるキャッシュプールを作成し、既存の LV MyVolGroup/rootvol をキャッシュボリュームに変換します、1ステップですべてできます:
# lvcreate --type cache --cachemode writethrough -l 100%FREE -n root_cachepool MyVolGroup/rootvol /dev/fastdisk
キャッシュモードには2つのオプションが利用できます:
writethroughは書き込まれたデータがキャッシュプール LV とオリジナルの LV の両方に保存されることが保証されます。キャッシュプール LV が保存されているデバイスが故障してもデータが消失することはありません。writebackは高い性能を発揮しますが、キャッシュに使っているドライブが故障したときにデータを喪失する危険性があります。
--cachemode を指定しなかった場合、デフォルトで writethrough が使われます。
キャッシュを削除する
上記で作成したキャッシュを削除したい場合:
# lvconvert --uncache MyVolGroup/rootvol
上記のコマンドでキャッシュに留まっている書き込みが origin LV に適用され、それからキャッシュが削除されます。他のオプションについては lvmcache(7) で説明されています。
RAID
LVM は、ソフトウェア RAID を作成するために使用できます。ハードウェア RAID を持っておらず、いずれにせよ LVM を使用するつもりであるならば、これは良い選択肢です。lvmraid(7) によると:
- lvm(8) RAID は、複数の物理デバイスを使用する論理ボリューム (LV) を作成して、パフォーマンスを向上させたり、デバイス障害に対する耐性を持たせたりするための1つの方法です。LVM では、それらの物理デバイスは単一のボリュームグループ (VG) 内の物理ボリューム (PV) です。
LVM RAID は RAID 0、RAID 1、RAID 4、RAID 5、RAID 6、RAID 10 をサポートします。それぞれのレベルに関する詳細は Wikipedia:Standard RAID levels を参照してください。
RAID をセットアップする
物理ボリュームを作成してください:
# pvcreate /dev/sda2 /dev/sdb2
物理ボリューム上にボリュームグループを作成してください:
# vgcreate MyVolGroup /dev/sda2 /dev/sdb2
lvcreate --type RAIDレベル を使用して論理ボリュームを作成してください。その他のオプションについては lvmraid(7) と lvcreate(8) を参照してください。
# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]
例:
# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol MyVolGroup /dev/sda2 /dev/sdb2
これは、20 GiB のミラー化された、"myraid1vol" という名前の論理ボリュームを、/dev/sda2 と /dev/sdb2 の上にある VolGroup00 内に作成します。
シンプロビジョニング
lvmthin(7) によると:
- 標準的な lvm(8) 論理ボリューム (LV) 内のブロックは、LV が作成されたときに割り当てられます。しかし、シンプロビジョニング LV 内のブロックは、それらのブロックが書き込まれたときに割り当てられます。そのため、シンプロビジョニング LV には仮想的なサイズが設定され、物理的に利用可能なストレージよりもさらに大きくすることができます。シンプロビジョニング LV のために提供される物理ストレージの容量は、ニーズに応じて後に拡大させることができます。
例: 仮想専用サーバを立てる
古典的なユースケースを挙げましょう。あなたは独自の VPS サービスを開始したいと考え、初めは約100個の VPS を 930 GiB ハードドライブ搭載の1台の PC 上でホストしているとしましょう。割り当てられたストレージのすべてを実際に使用する VPS はほとんど存在しないため、各 VPS に 9 GiB を割り当てるのではなく、各 VPS に最大 30 GiB を使用できるようにし、シンプロビジョニングを使うことで各 VPS に実際に使用している量のハードドライブ領域を割り当てるようにします。930 GiB のハードドライブは /dev/sdb であるとします。以下がそのセットアップです。
ボリュームグループ MyVolGroup を準備します。
# vgcreate MyVolGroup /dev/sdb
シンプール LV MyThinPool を作成します。この LV はストレージ用のブロックを提供します。
# lvcreate --type thin-pool -n MyThinPool -l 95%FREE MyVolGroup
シンプールは2つのサブボリュームから成ります: データ LV とメタデータ LV です。このコマンドは両方を自動的に作成します。しかし、いずれかが完全に一杯になると、シンプールは動作を停止してしまいます。さらに、LVM は現在、それらのボリュームの縮小をサポートしていません。これが、上記のコマンドで 5% の追加領域を用意している理由です。シンプールのデータサブボリュームかメタデータサブボリュームを拡張する必要が発生する場合に備えているのです。
各 VPS に対してシン LV を作成します。これは、ユーザに対してルートパーティションとして公開されるブロックデバイスです。
# lvcreate -n SomeClientsRoot -V 30G --thinpool MyThinPool MyVolGroup
そのブロックデバイス /dev/MyVolGroup/SomeClientsRoot は、ルートパーティションとして VirtualBox が使用することができます。
シンスナップショットを使用してスペースを節約する
シンスナップショットは、それ自体がシン LV なので、通常のスナップショットよりも遥かに強力です。シンスナップショットが持つ長所の完全なリストは Red Hat のガイド [2] を参照してください。
VPS が作成されるたびに Linux をゼロからインストールするのではなく、基本的な Linux 環境が含まれるただ1つのシン LV から始める方が容量を効率的に使用できます:
# lvcreate -n GenericRoot -V 30G --thinpool MyThinPool MyVolGroup *** /dev/MyVolGroup/GenericRoot に Linux をインストール ***
そして、各 VPS に対してその LV のスナップショットを作成します:
# lvcreate -s MyVolGroup/GenericRoot -n SomeClientsRoot
このように、シンプールには (少なくとも最初は) 全 VPS に対して共通のデータのコピーがただ1つだけ存在します。追加の利点として、新しい VPS の作成が瞬時に行われます。
これらはシンスナップショットであるため、GenericRoot への1回の書き込み操作において COW 操作は、スナップショット毎に1回ではなく、合計で1回しか行われません。これにより、GenericRoot の更新は、各 VPS が通常のスナップショットである場合よりも効率的なります。
例: ゼロダウンタイムでストレージをアップグレードする
VPS のホスティング以外にもシンプロビジョニングの活用法は存在します。シンプロビジョニングを使用して、すでにマウントされているファイルシステムをアンマウントすることなく、その実効容量を増やす方法を紹介しましょう。ここでは (再び)、サーバに1台の 930 GiB ハードドライブが搭載されていると仮定します。環境は VPS ホスティングのときと同じですが、シン LV が1つしかなく、LV のサイズはシンプールのサイズよりも遥かに大きいとします。
# lvcreate -n MyThinLV -V 16T --thinpool MyThinPool MyVolGroup
この追加の仮想領域は、シンプールを拡張することで後に実際のストレージで埋めることができます。
しばらくして、ストレージのアップグレードが必要になり、新しいハードドライブ /dev/sdc がサーバに接続されたとします。シンプールの容量をアップグレードするには、新しいハードドライブを VG に追加します:
# vgextend MyVolGroup /dev/sdc
次に、シンプールを拡張します:
# lvextend -l +95%FREE MyVolGroup/MyThinPool
このシン LV のサイズは 16 TiB なので、最終的にファイルシステムをアンマウントしてサイズ変更するはめになるまでに、さらに 15.09 TiB のハードドライブ領域を追加できます。
トラブルシューティング
LVM コマンドが機能しない
- 適切なモジュールをロードしてください:
# modprobe dm_mod
dm_mod モジュールは自動的にロードされるはずです。そうならない場合は、明示的にモジュールを起動時にロードするようにしてください。
- lvm コマンドを次のように試してみてください:
# lvm pvdisplay
論理ボリュームが表示されない
既存の論理ボリュームをマウントしようとしても、lvscan に表示されない場合、以下のコマンドによってボリュームを有効にすることができます:
# vgscan # vgchange -ay
リムーバブルメディア上の LVM
症状:
# vgscan
Reading all physical volumes. This may take a while... /dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error /dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error /dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error /dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error Found volume group "backupdrive1" using metadata type lvm2 Found volume group "networkdrive" using metadata type lvm2
病因: 最初にボリュームグループを無効にしないで外付けの LVM ドライブを取り外したこと。切断する前に、次を実行するようにしましょう:
# vgchange -an ボリュームグループ名
修復: あなたがすでに vgchange -ay vg でそのボリュームグループのアクティブ化を試み、先の Input/output エラーを見たと仮定します:
# vgchange -an ボリュームグループ名
外部ドライブを取り外し、数分待ってください。
# vgscan # vgchange -ay ボリュームグループ名
LVM とリムーバブルメディアでサスペンド/復帰
LVM をリムーバブルメディア (外部 USB ドライブなど) で正常に動作させるには、外部ドライブのボリュームグループをサスペンド前に非アクティブ化させる必要があります。これが行われないと、(復帰後に) dm デバイスでバッファ I/O エラーが発生する場合があります。この理由により、外部ドライブと内部ドライブを同じボリュームグループ内に混在させることは推奨されません。
外部 USB ドライブのあるボリュームグループを自動的に非アクティブ化するには、以下の方法でそれぞれのボリュームグループに sleep_umount タグを付けてください:
# vgchange --addtag sleep_umount 外部ボリュームグループ
このタグを設定したら、systemd の以下のユニットファイルを使用して、サスペンド前にボリュームを適切に非アクティブ化します。復帰時には、それらのボリュームは LVM によって自動的にアクティブ化されます。
/etc/systemd/system/ext_usb_vg_deactivate.service
[Unit] Description=Deactivate external USB volume groups on suspend Before=sleep.target [Service] Type=oneshot ExecStart=-/etc/systemd/system/deactivate_sleep_vgs.sh [Install] WantedBy=sleep.target
あと以下のスクリプトです:
/etc/systemd/system/deactivate_sleep_vgs.sh
#!/bin/sh
TAG=@sleep_umount
vgs=$(vgs --noheadings -o vg_name $TAG)
echo "Deactivating volume groups with $TAG tag: $vgs"
# $TAG タグのあるボリュームグループに属する論理ボリュームをアンマウントします
for vg in $vgs; do
for lv_dev_path in $(lvs --noheadings -o lv_path -S lv_active=active,vg_name=$vg); do
echo "Unmounting logical volume $lv_dev_path"
umount $lv_dev_path
done
done
# sleep_umount でタグ付けされたボリュームグループを非アクティブ化します
for vg in $vgs; do
echo "Deactivating volume group $vg"
vgchange -an $vg
done
最後に、そのユニットを有効化してください。
連続している論理ボリュームのサイズ変更に失敗する
論理ボリュームを拡張しようとすると以下のエラーが表示される場合:
" Insufficient suitable contiguous allocatable extents for logical volume "
明示的に連続するように割り当てるポリシー (オプション -C y または --alloc contiguous) を使って論理ボリュームが作成されており、ボリュームの近隣に連続したエクステントが存在しないのが原因です。[3]
この問題を修正するには、論理ボリュームを拡張する前に、lvchange --alloc inherit 論理ボリューム で割り当てポリシーを変更してください。連続割り当てポリシーを使い続ける必要がある場合、空きエクステントが十分存在するディスク領域にボリュームを移動してください。[4] を参照。
"grub-mkconfig" コマンドで "unknown filesystem" エラーが発生する
grub.cfg を生成する前にスナップショットボリュームは削除するようにしてください。
シンプロビジョニングボリュームに root を配置する場合にタイムアウトが発生する
大量のスナップショットを使用した場合、thin_check の実行時間が長くなるためルートデバイスがタイムアウトしてしまうことがあります。そのためブートローダーの設定に rootdelay=60 カーネルブートパラメータを追加してください。あるいは、thin_check によるブロックマップのチェックをスキップし ([5] を参照) Initramfs を再生成してください:
/etc/lvm/lvm.conf
thin_check_options = [ "-q", "--clear-needs-check-flag", "--skip-mappings" ]
シャットダウンが遅くなる
RAIDやスナップショット、シンプロビジョニングを使用していてシャットダウンが遅くなる場合、lvm2-monitor.service が起動していることを確認してください。FS#50420 を参照。
シンプロビジョニングされたスワップボリューム上にハイバネートする
サスペンドとハイバネート#thinly-provisioned LVM ボリュームへのハイバネーション を参照してください。