LVM cacheでSSD書き込みキャッシュ階層を本番構築する設計とキャッシュ障害切り戻し

LVM cacheとSSD書き込みキャッシュ階層が必要になる背景

HDDベースのストレージに対してランダム書き込みの多いワークロードを継続的に投入すると、ディスクI/Oがシステム全体のボトルネックになります。新しいストレージを丸ごとSSDへ置き換えるのが理想ですが、大容量データを扱うデータベースサーバや仮想化ホストでは、コストと容量の制約からHDDを完全に廃止できないケースが多くあります。

LVM cache（lvm2 の dm-cache ドライバを使うキャッシュ機能）は、既存のHDD論理ボリュームの前段に小容量SSDをキャッシュ層として配置し、ホットデータのアクセスを高速化する仕組みです。カーネルの dm-cache はLinux 3.9から統合されており、lvm2 ツールセットで管理できます。OSS の範囲で完結するため、追加コストなしにストレージ階層化を実現できる点が実務上のメリットです。

ただし、本番環境への適用には「書き込みキャッシュモードの選択」「キャッシュデバイス障害時のデータ保全」という2つの設計判断が避けられません。この記事ではその設計から手順・検証・切り戻しまでを通して扱います。

本番構築前の設計判断：writeback か writethrough か

LVM cacheには主に2つのキャッシュモードがあります。本番適用前にどちらを選ぶかを確定させておくことが、障害対応の複雑さに直結します。

writethrough（デフォルト）

書き込みをキャッシュとオリジンデバイスの両方に同時に行うモードです。読み込みはキャッシュから高速化されますが、書き込みはオリジン（HDD）の速度に律速されます。キャッシュデバイスが失われてもオリジンのデータは完全に保たれるため、SSD障害時のリスクが低く、本番の「まず試す」構成として選ばれやすいです。

writeback

書き込みをまずキャッシュへ行い、後からオリジンへ非同期に書き戻すモードです。書き込みスループットがキャッシュデバイス（SSD）の性能まで向上しますが、キャッシュデバイスが予期せず失われた場合、未書き戻しのダーティブロックが消え、オリジンデータが不整合になるリスクがあります。RAIDや電源保護付きNVMeキャッシュと組み合わせるか、定期的なフラッシュ運用が必須です。

一般的な指針として、書き込みスループットより可用性を優先する本番DBサーバにはwritethroughを、バッチ処理や仮想マシンイメージのような「再作成可能なデータ」にはwritebackを検討します。どちらのモードも構築後に変更できますが、変更時に一時的な書き込み停止が発生するため、計画的に実施する必要があります。

LVM cacheの構築手順

以下の手順は RHEL 9 / AlmaLinux 9 / Ubuntu 24.04 LTS の lvm2 パッケージ標準構成を前提とします。デバイス名は環境に合わせて読み替えてください。

1. キャッシュデバイスの物理ボリューム作成とVGへの追加

SSDがまだVGに属していない場合、物理ボリュームを作成してから既存のVGへ追加します。

# SSDをPVとして初期化
pvcreate /dev/nvme0n1

# 既存VGへ追加（VG名：datavg と仮定）
vgextend datavg /dev/nvme0n1

2. キャッシュプール論理ボリュームの作成

キャッシュプールはデータ用とメタデータ用の2つのLVから構成されます。lvcreate の --type cache-pool を使うと、lvm2が自動でメタデータLVを確保します。--cachemode でモードを指定します（省略時はwritethrough）。

# SSD上に20GBのキャッシュプールを作成（writeback指定の例）
lvcreate --type cache-pool \
  --cachemode writeback \
  -L 20G \
  -n cache_pool \
  datavg /dev/nvme0n1

3. キャッシュプールをオリジンLVへアタッチ

対象の論理ボリューム（ここでは data_lv）にキャッシュプールを紐付けます。このコマンドの実行後、即座にキャッシュが機能し始めます。

lvconvert --type cache \
  --cachepool datavg/cache_pool \
  datavg/data_lv

実行中にサービスを止める必要はありませんが、本番適用前にスナップショットまたはバックアップを取得しておくことを推奨します。

動作検証とキャッシュ状態の確認

構築後は lvs コマンドでキャッシュの動作状態を確認します。

lvs -o +cache_mode,cache_policy,cache_settings,cache_used_blocks,cache_dirty_blocks datavg/data_lv

出力の主要フィールドの意味は次のとおりです。

• CacheUsedBlocks：キャッシュに格納されたブロック数。アクセスに応じて増加します。
• CacheDirtyBlocks：writebackモード時のダーティブロック数。ゼロに近い状態が望ましいです。
• CacheReadHits / CacheWriteHits：ヒット率の算出に使います。

より詳細な統計は dmsetup status datavg-data_lv でも確認できます。キャッシュ構築直後はヒット率が低く、ワークロードの継続によってホットブロックがキャッシュに蓄積されていく挙動が正常です。

想定例として、ランダム書き込みが多いデータベース用LVにwritethroughキャッシュを30GB設定した場合、ウォームアップ期間（数時間〜数日）を経るとReadHitが60〜80%台に達するケースが一般的に報告されています。ただし実際の効果はワークロードのアクセスパターンに大きく依存するため、本番投入前にステージング環境で計測することが望まれます。

キャッシュ障害時の切り戻し手順

SSDが故障・交換になる場合や、キャッシュを撤去してシンプルな構成に戻す必要が生じた場合に備え、切り戻し手順を事前に把握しておくことが本番運用の前提です。

計画的な切り戻し（SSD正常時）

SSDが正常に動作している状態でキャッシュを外す場合、lvconvert --uncache を使います。このコマンドはダーティブロックをオリジンに書き戻してからキャッシュプールを解除します。

lvconvert --uncache datavg/data_lv

書き戻し完了後、キャッシュプールLVは自動的に削除されます。オリジンLVはキャッシュなしの通常LVとして継続して使用できます。ダーティブロックが多い場合は書き戻しに時間がかかるため、I/Oの少ないメンテナンス時間帯に実施します。

緊急切り戻し（SSD障害時・writebackモード）

writebackモードでSSDが突然消失した場合、オリジンLVは不整合状態になる可能性があります。この状態でファイルシステムをマウントすると破損が拡大します。まずVGをアクティベートせずに状態を確認します。

# VG状態確認（アクティベートしない）
vgdisplay datavg
lvs --noheadings -o lv_attr,lv_name datavg

lv_attr の1文字目が C（cached）のままになっている場合、カーネルはキャッシュデバイスを探そうとします。新しいSSDへの交換が完了していない状態では、lvchange --activationmode degraded を使ってオリジンのみを強制的にアクティブにする方法があります。ただしこの操作はダーティブロックの損失を前提とするため、事前にオリジンデバイスのddイメージやLVMスナップショットがあれば先に退避します。

# degradedモードで強制アクティベート（ダーティブロック損失を覚悟の上で）
lvchange --activationmode degraded -ay datavg/data_lv

# その後キャッシュを外す
lvconvert --uncache datavg/data_lv

強制アクティベート後はファイルシステムの整合性チェック（fsck または xfs_repair）を必ず実施します。writebackモードをDBや重要データに使用する場合は、この切り戻しリスクを織り込んだ設計が不可欠です。

2026年現行環境での注意点と動向

lvm2 の dm-cache 実装は長年安定していますが、2026年時点で運用に影響する変更点や注意事項があります。

RHEL 9 / AlmaLinux 9 でのデフォルト変更

RHEL 9.x 系では lvm2 の設定ファイル（/etc/lvm/lvm.conf）の cache_mode デフォルトが明示的にwritethroughになっています。過去にRHEL 7/8でwritebackがデフォルトだった時代のドキュメントを参照している場合は注意が必要です。構築時に必ず --cachemode オプションを明示することで、バージョン差異による意図しない動作を防げます。

bcache・ZFS L2ARC との使い分け

同様のSSDキャッシュ階層化として bcache（カーネル組み込み）や ZFS の L2ARC/ZIL があります。bcache はLVMに依存しない構成が取れる点で柔軟ですが、LVM管理のボリュームに後から追加する用途では dm-cache（lvm cache）の方がオペレーション上の一貫性が保ちやすいです。ZFSを使っている場合は L2ARC/ZIL がZFS自体の機能として完結するため、LVM cacheとの併用は通常不要です。

systemdとの連携と起動順序

キャッシュ構成のVGを持つホストをsystemdで管理する場合、SSDのデバイス検出順によってはVGのアクティベーションが遅延し、サービス起動失敗の原因になることがあります。lvm2-activation-generator が生成するユニットを確認し、依存関係が正しく設定されているかをブート直後の systemctl status lvm2-activation.service で確認しておくと、予期しない障害を早期に発見できます。

モニタリングとアラートの組み込み

キャッシュを本番に組み込む場合、CacheDirtyBlocksの増大やキャッシュヒット率の急落を監視対象に加えることを推奨します。Prometheusを使っている環境では node_exporter の dmstats コレクターや lvm2 の外部エクスポーターを組み合わせることで、キャッシュ状態をダッシュボードから継続監視できます。アラートの閾値はワークロードによって異なるため、最初の数週間は傾向を観察しながら設定します。