【LVM完全マスター付録】プロ領域へ踏み込む！シンプロビジョニング・LVMキャッシュ・ストライピング徹底解説

LVMの「深淵」を覗く準備はいいか。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回のLVM完全マスター連載、完走お疲れ様でした。すでにあなたは、日常のサーバー運用においてディスク管理で困ることはないレベルに達しています。

しかし、LVMの世界はもっと奥深いのです。
近年のクラウド技術やコンテナ技術（Dockerなど）の裏側では、私たちがまだ触れていない「LVMの高度な機能」がバリバリ使われています。

本記事は「付録」ですが、中身は超実践的です。
LVMを極めたいエンジニアのために、教科書の先にあるテクニックを網羅しました。

---

第1章：嘘をつく技術「シンプロビジョニング (Thin Provisioning)」

通常、LVMで100GBのLVを作ると、物理ディスクからもきっちり100GBが消費されます。
これを「シックプロビジョニング（Thick Provisioning）」と呼びます。

対して、「シンプロビジョニング（Thin Provisioning）」は、「使うと言った分だけ確保するのではなく、実際に書かれた分だけ確保する」技術です。

何が嬉しいの？（オーバーコミット）

例えば、物理ディスクが1TBしかないのに、「100GBのLVを20個（計2TB）」作ることができます。
OSからは「2TBある」ように見えますが、実際にデータが書き込まれて1TBに達するまでは正常に動きます。
これを「オーバーコミット」と呼びます。
VPS業者やクラウド事業者が、限られた物理リソースを多くのユーザーに貸し出せるのは、この技術のおかげです。

構築手順

シンプロビジョニングを使うには、まず「Thin Pool」という専用のプールを作り、そこから「Thin LV」を切り出します。

1. Thin Poolの作成

# vg_storageの中に、100GBのThin Pool "tp_pool01" を作成
sudo lvcreate -L 100G -T vg_storage/tp_pool01

2. Thin LVの作成

# tp_pool01から、仮想サイズ1TBのThin LV "lv_thin_data" を作成
sudo lvcreate -V 1T -T vg_storage/tp_pool01 -n lv_thin_data

これで、物理100GBのプールの中に、論理1TBのLVが誕生しました。
lvs コマンドで見ると、実使用量（Data%）が非常に少ないことが分かります。

---

第2章：爆速ストレージを安く作る「LVMキャッシュ」

「HDDの大容量は欲しいけど、SSDの速度も欲しい」。
そんなワガママを叶えるのがLVMキャッシュ（dm-cache）です。
小容量の高速デバイス（NVMe SSDなど）を、大容量の低速デバイス（HDD）の「キャッシュ」として配置する技術です。

2つのキャッシュモード

1. Writeback（ライトバック）：
   読み書き両方を高速化します。データは一旦SSDに書かれ、暇な時にHDDに同期されます。
   爆速ですが、SSDが壊れるとデータが消えるリスクがあります。
2. Writethrough（ライトスルー）：
   読み込み（Read）だけを高速化します。書き込みはHDDに直接行います。
   速度はそこそこですが、SSDが壊れてもデータは安全です。

今回は、速度重視のWriteback構成を作ってみましょう。

構築手順

前提：
・HDDのVG：vg_hdd
・HDD上の遅いLV：lv_slow（すでにデータが入っている）
・SSDのPV：/dev/nvme0n1p1（これをvg_hddに追加しておく）

1. キャッシュ用プール（メタデータ+データ）の作成

# SSD上にキャッシュデータ領域を作成
sudo lvcreate -n lv_cache_data -L 100G vg_hdd /dev/nvme0n1p1

# SSD上にキャッシュメタデータ領域を作成（データ領域の1/1000程度でOK）
sudo lvcreate -n lv_cache_meta -L 120M vg_hdd /dev/nvme0n1p1

# キャッシュプールとして合体させる
sudo lvconvert --type cache-pool --poolmetadata vg_hdd/lv_cache_meta vg_hdd/lv_cache_data

2. 既存のLVにキャッシュを紐付ける

# lv_slow にキャッシュプールを結合（モードはwriteback）
sudo lvconvert --type cache --cachepool vg_hdd/lv_cache_data --cachemode writeback vg_hdd/lv_slow

これで完了です！
OSからは今まで通り /dev/vg_hdd/lv_slow として見えますが、アクセス速度はNVMe SSD並みに爆速化しています。
データベースサーバーなどで絶大な効果を発揮します。

---

第3章：I/Oを分散させて高速化「LVMストライピング」

RAID 0（ストライピング）と同じことをLVMで行う技術です。
通常、LVMはデータをディスク1に書き込み、溢れたらディスク2に書き込みます（リニアモード）。
ストライピングを使うと、データをディスク1とディスク2に同時に分散して書き込みます。

メリットとデメリット

• メリット： 読み書き速度がディスクの本数分だけ倍増します（理論値）。
• デメリット： ディスクが1本でも壊れると、全データが飛びます（RAID 0と同じリスク）。

構築手順

VG（vg_stripes）の中に、3本の物理ディスク（sdb, sdc, sdd）があるとします。

# 3本のディスクに分散してLVを作成（ストライプサイズ64KB）
sudo lvcreate -i 3 -I 64k -n lv_fast -L 30G vg_stripes

• -i 3 : 3本のディスクに分散する（ストライプ数）。
• -I 64k : 64KBごとにデータを区切って分散する。

大量のデータをシーケンシャルアクセス（連続読み書き）する動画編集サーバーや、ログ解析サーバーなどで効果的です。

---

第4章：特定のディスクを無視させる「フィルタリング」

LVMを使っていると、「OSインストール時に誤ってSANストレージ（共有ディスク）を初期化してしまった」という事故が稀に起きます。
これを防ぐために、LVM設定ファイルで「触ってはいけないディスク」を除外する設定が重要です。

/etc/lvm/lvm.conf の編集

filter または global_filter という項目を探します。

# 例：sdaとsdbだけ許可し、それ以外（r=reject）は全て拒否する設定
filter = [ "a|^/dev/sda.*|", "a|^/dev/sdb.*|", "r|.*|" ]

• a : Accept（許可）
• r : Reject（拒否）

この設定をしておけば、誤って外付けUSBHDDやSANストレージに対して pvcreate を打っても、「除外されています」とエラーになり、事故を防げます。

---

第5章：マニアックなコマンドチートシート

本編では紹介しきれなかった、しかし知っていると「おっ、こいつ出来るな」と思われる便利コマンド集です。

PV上のデータ配置を見る

sudo pvs -o +pv_used

どのPVがどれくらい使われているかを詳細に表示します。

LVを別のディスクに移動する（稼働中）

特定のLVだけを、古いディスク（sdb）から新しいディスク（sdc）へ移動させたい場合。

sudo pvmove -n lv_name /dev/sdb /dev/sdc

ディスク全体ではなく、LV単位での引っ越しが可能です。

LVM設定のバックアップを手動で取る

自動バックアップだけでなく、作業前に手動で取りたい場合。

sudo vgcfgbackup vg_storage

/etc/lvm/backup/ に現在の構成が保存されます。

---

まとめ：LVMは「インフラの粘土」である

今回は、LVMのさらに深い世界（シンプロビジョニング、キャッシュ、ストライピング）を紹介しました。
これらは強力ですが、複雑さも増すため、トラブル時の切り分けが難しくなる諸刃の剣でもあります。

しかし、「ディスク＝硬い箱」という概念を捨て、「ディスク＝自由にこねられる粘土」として扱えるようになること。
これこそがLVMの本質であり、現代のクラウドインフラを支える思想そのものです。

この連載（全8回＋付録）の内容をマスターしたあなたは、もうどこに出しても恥ずかしくないLinuxインフラエンジニアです。
自信を持って、サーバー構築の現場で活躍してください！