LVM シンプロビジョニング本番導入｜プール枯渇アラートと緊急拡張ロールバック手順

シンプロビジョニングを本番に持ち込む前に押さえたいリスク構造

LVMのシンプロビジョニング（Thin Provisioning）は、ストレージの物理容量を仮想的に過剰割り当てできる機能です。開発・検証環境での採用は広まりましたが、本番環境への展開をためらう運用チームは今も少なくありません。その理由のほぼすべてが「プール枯渇時に何が起きるか分からない」という一点に集約されます。

シンプールの空き容量がゼロになると、シンLV（論理ボリューム）への書き込みはI/Oエラーを返します。ファイルシステムはread-onlyへの自動フォールバックを試みますが、これはデータ保護の観点では正しい動作であっても、サービス断として現れます。つまり「枯渇させない運用設計」と「枯渇を検知して即座に拡張する仕組み」の両方が揃って初めて、本番採用が成立します。本記事では作成手順から監視・緊急拡張・ロールバックまでを一本の運用シナリオとして整理します。

シンプールと論理ボリュームの初期構成手順

前提として、物理ボリューム（PV）とボリュームグループ（VG）は既に構成済みとします。ここでは VG名を vg_data、プール用に確保した物理領域を 200 GiB として話を進めます。

シンプールの作成は lvcreate の --type thin-pool オプションで行います。メタデータ領域はデフォルトで自動計算されますが、大規模運用では --poolmetadatasize で明示的に確保するほうが安全です。目安はプールサイズの 0.1〜0.2% 程度ですが、スナップショットを多用する構成では余裕を持たせます。

# シンプール作成（プール名: tp_main）
lvcreate --type thin-pool -L 200G --poolmetadatasize 512M -n tp_main vg_data

# シンLV作成（仮想サイズ 500 GiB を割り当て）
lvcreate --type thin -V 500G --thinpool vg_data/tp_main -n lv_app

# ファイルシステム作成・マウント
mkfs.xfs /dev/vg_data/lv_app
mount /dev/vg_data/lv_app /mnt/app

シンプールには --discards passdown（デフォルト）を設定しておくと、ファイルシステム側の TRIM/DISCARD 命令がブロックデバイス層まで伝播し、使用済みブロックの回収効率が上がります。XFS の場合は mount -o discard オプションも合わせて指定します。ただし書き込みが非常に多いワークロードでは DISCARD の頻度が性能に影響することがあるため、定期 fstrim による手動実行と使い分ける運用チームも多く見られます。

プール枯渇を検知するアラート設計

監視の設計は「閾値超え時に通知」と「枯渇直前での自動拡張トリガー」の二段階に分けるのが現場での定石です。

lvs コマンドと systemd timer によるポーリング

最もシンプルな方法は、lvs コマンドで使用率を定期取得し、閾値を超えたらアラートを送るスクリプトを systemd timer で動かすことです。lvs --noheadings -o data_percent vg_data/tp_main の出力は数値のみとなるため、シェルスクリプトや Python による比較処理に組み込みやすい形式です。

systemd timer の設定例では OnCalendar=*:0/5 として5分間隔でポーリングするユニットを用意します。lvs の出力が 80 を超えた時点でメール・Slack・PagerDuty 等の通知チャネルへ投げる構成が一般的です。

lvm2 の event_activation と dmeventd の活用

lvm2 には dmeventd（Device Mapper Event Daemon）というイベント監視デーモンが同梱されています。シンプール用プラグイン libdevmapper-event-lvm2thin.so を使うと、プールの使用率が設定した閾値に達した時点で LVM 自体がイベントを検知し、自動的に拡張処理を試みます。有効化は lvchange --monitor y vg_data/tp_main で行います。

ただし dmeventd の自動拡張はあくまで「VG 内に未割り当て領域が存在する場合」に限られます。VG 自体の空きが底をついていると自動拡張は発動しません。このため dmeventd の監視と並行して VG 残量の監視も欠かせません。Prometheus + node_exporter の lvm コレクターを利用しているチームでは、node_lvm_vg_free_bytes メトリクスで VG 残量を Grafana に可視化し、PV 追加のリードタイムを確保する運用が定着しています。

枯渇発生時の緊急拡張手順

アラートを受けてシンプールを拡張する手順は、状況に応じて二つのパスに分かれます。

パス A：VG に未使用領域が残っている場合
これが最も迅速な対応です。lvextend でプールサイズを増やします。シンプールの拡張はオンライン（マウントしたまま）で実行できます。

# プールを 50 GiB 拡張（+指定で相対増量）
lvextend -L +50G vg_data/tp_main

# 拡張後の確認
lvs -o lv_name,lv_size,data_percent vg_data

パス B：VG の空き容量も不足している場合
新たな物理ディスクまたは LUN を PV として追加し、VG を拡張してからプールを伸ばします。クラウド環境であれば EBS や Persistent Disk のアタッチ後、pvcreate→vgextend→lvextend の三段階で対応します。この一連の操作もすべてオンラインで実施可能です。

# 新規デバイスを PV として初期化（例: /dev/sdc）
pvcreate /dev/sdc

# VG に追加
vgextend vg_data /dev/sdc

# プール拡張
lvextend -L +100G vg_data/tp_main

拡張後にサービスが自動復旧しない場合は、ファイルシステムが read-only に落ちていないか確認します。dmesg | grep -E "EXT4|XFS|readonly" でカーネルログを確認し、read-only になっている場合は mount -o remount,rw /mnt/app で再マウントします。XFS は xfs_repair が必要なケースもあるため、ログの確認を飛ばして再マウントだけ試みるのは避けてください。

切り戻しとロールバックの考え方

シンプロビジョニング固有のロールバック手段として、スナップショットを活用した巻き戻しが挙げられます。シンLV のスナップショット作成はプール内領域を消費しますが、作成時点のブロック変更差分のみを記録するため、厚いスナップショット（thick snapshot）に比べて初期コストが低く抑えられます。

リリース前後のスナップショットを取得しておけば、問題発生時に lvconvert --merge で前の状態へ戻す操作が可能です。ただし merge はボリュームのアンマウントか、次回マウント時の自動適用として実行されるため、オンラインでの即時切り戻しは行えません。サービス停止を許容できる保守窓での操作が原則です。

緊急拡張そのもののロールバックについては、「一度拡張したプールを縮小する」操作は LVM 側がサポートしていません（シンプールの lvreduce は非対応）。過剰に拡張してしまっても容量が無駄になるだけでデータは保全されるため、緊急時は「少し多め」に拡張してリスクを下げるほうが賢明です。PV を後から除去したい場合は pvmove でデータを移動させてから vgreduce する手順が必要になります。

2026年現行環境での差分と注意点

RHEL 9 系（および AlmaLinux 9・Rocky Linux 9）では lvm2 2.03 系が標準となっており、/etc/lvm/lvm.conf の issue_discards や thin_pool_autoextend_threshold といったパラメータが以前のバージョンとは異なる挙動をする場合があります。特に thin_pool_autoextend_threshold と thin_pool_autoextend_percent を lvm.conf に設定している既存環境を RHEL 8 から RHEL 9 へ移行した際に、dmeventd による自動拡張が期待通りに動作しないケースが報告されています。移行後は必ず lvs --monitor の出力と dmeventd のログを確認してください。

Ubuntu 24.04 LTS（Noble Numbat）では lvm2 2.03.21 以降が収録され、systemd との統合が強化されています。lvm2-monitor.service の起動順序が変わったため、ブート時に dmeventd が起動していないように見えるケースがありますが、systemctl status lvm2-monitor.service で状態を確認し、必要に応じて systemctl enable --now lvm2-monitor.service を実行してください。

コンテナ環境では別の考慮が必要です。Kubernetes のストレージバックエンドとして LVM シンプロビジョニングを使う構成（topolvm 等）では、PVC の動的プロビジョニング時にプール残量をスケジューラが考慮するよう CSI ドライバの設定を確認しておく必要があります。プールの枯渇は Pod の起動失敗として現れるため、アプリケーション層からは原因が見えにくい障害になりがちです。ノードの lvs 出力とクラスタのイベントログを両方参照できる監視体制が求められます。

2026年時点でシンプロビジョニングの本番採用を検討する場合、技術的な成熟度は十分に達しています。課題の大半は「監視の抜け」と「運用手順の未整備」に起因しており、本記事で示したような枯渇検知から緊急拡張・切り戻しまでの手順を事前に整えておくことが、安定した本番運用の前提条件といえます。