高速かつ低コストの大容量ストレージ：SSD上でHDDをキャッシュするためのLVMの利用

2025年7月27日原文(quantum5.ca)

概要

SSDとHDDのハイブリッドストレージ構成の利点と時代背景
LVMキャッシュによるSSDキャッシュ付きRAID 1 HDDアレイの構築手順
RAID 1によるHDD冗長化と障害対策の重要性
LVMの基本概念とセットアップ方法の解説
mdadmによるRAID 1作成、SSDパーティション作成、LVMキャッシュ設定の実践手順

SSDキャッシュ付きRAID 1 HDDストレージ構成の構築

SSD はランダムI/Oに優れた速度を持つが、 HDD は大容量・低コストストレージ用途
頻繁にアクセスされるデータのみ SSDキャッシュ に保存し、他はHDDに保存する構成
かつては SSHD や ZFSのL2ARC などが主流だったが、SSD価格低下で一般用途では不要に
大容量データの一部だけ高速アクセスが必要な場合（ミラーサイトやローカルLLM運用等）で有効
ZFSはLinux互換性の課題があるため、 LVM と mdadm を組み合わせた構成を選択

LVMキャッシュを選ぶ理由

Linuxには他にも bcache や EnhanceIO などのブロックデバイスキャッシュ手法あり
- bcacheはブロックデバイス全体の所有や設定の永続性・データ破損報告が難点
- EnhanceIOはメンテナンスされておらず非推奨
LVMは構成情報の永続性・柔軟な管理・既存環境との親和性で優位
LVMの知識や運用経験がある場合、導入・運用の学習コストが低い

LVMの基礎知識

ブロックデバイス ：/dev/sdaなど、一定サイズのデータブロックを持つデバイス
パーティション ：/dev/sda1など、ブロックデバイスを分割した論理領域
LVMの3要素 ：
- Physical Volume (PV) ：LVMで利用する物理ストレージ
- Volume Group (VG) ：複数PVを束ねて管理する単位
- Logical Volume (LV) ：VG上に作成する論理パーティション
LVは通常のパーティションのように利用可能で、サイズ拡張や動的割り当てが容易
キャッシュ付きLV や Thin pool 等、高度なLVも利用可能

ハードウェア構成例

4TB SATA HDD x2（/dev/sda, /dev/sdb）を用意
2TB SSD（/dev/nvme0n1）の一部（例：100GiB）をキャッシュ用パーティションとして利用
lsblk コマンドでデバイス確認を推奨
コマンド実行前は wipefs 等でデータ消去やパーティション確認を徹底

なぜHDDにRAID 1を使うのか

HDDは機械的故障が避けられない ため、冗長化が重要
データを冗長化せず単一ドライブやRAID 0で運用すると、故障時の復旧・再構築コストが高い
RAID 1なら 片方のドライブ故障時もサービス継続 が可能
異なるメーカーや型番のドライブを組み合わせることで同時故障リスク低減

HDDパーティション分割の注意点

RAID構成時、 全デバイスのサイズ一致が必須
「4TB」表記でも実容量に差があるため、正確なセクタ数でパーティションを切る
- 例：4,000,000,000,000バイト ÷ 512バイト = 7,812,499,999セクタ
gdisk コマンドでGPTパーティションテーブル作成
- パーティションタイプは「Linux RAID (fd00)」
- 識別用に名前を付与すると管理が容易

mdadmによるRAID 1アレイ作成

mdadm --create でRAID 1アレイ（例：/dev/md0）を作成
作成後、 /etc/mdadm/mdadm.conf に定義を追加し、initramfsを更新
/proc/mdstat で同期状況を確認可能（同期中も作業継続可能）

SSDキャッシュパーティションの作成

SSDの未使用領域 にキャッシュ用パーティションを作成
キャッシュパーティションは LVM LVではなく物理パーティション とすること
- ネストしたLVM構成は不安定で、データ破損リスクが高い
パーティション作成後、LVM PVとして登録し、VGに追加

この後の手順（LVMキャッシュLVの作成、ファイルシステム作成、マウント、監視方法など）は省略されていますが、上記の流れで 信頼性と高速性を両立したストレージ構成 を構築可能です。

Hackerたちの意見

キャッシングのYMMVはアクセスパターンによるけど、私の場合、もっとも一貫してキャッシュ可能なパターンはext4のジャーナルだね。サイズが小さくて、すごい数のIOPSがヒットすることが多い。ext4は外部ジャーナルをサポートしていて、遅いSMRディスクがたくさんある場合に、それを単一のSSDに移動するのが過去にはうまくいった。ただ、SSDが故障すると、いくつかのディスクからのデータ損失の根本原因になっちゃう（リードキャッシュとは違って）。私が働いていたところでは、HDFSを使っていて、RAIDよりも複数のディスクのJBODレイアウトが好きだったから、ノードが完全に故障しても問題なかったし、大きなファイルをたくさんの固定サイズのファイル（blk_という名前）として書き込むことで、メタデータ操作がたくさんあった。SSDはその頃高かったけど、ここ10年で安くなってきたね。

└

ハイブリッドドライブを思い出すな。NVMが故障したときは、対処が大変だった。個人的には、安定性の観点から、ドライブから不揮発性メモリにキャッシュするのは悪いアイデアだと思う。

└

ZFSにも同じことが言えるよ。「zil」デバイスを作るためのプロビジョニングがある - ZFS Intent Log、基本的にはジャーナルだね。ZFSはこのジャーナルが明示的に使い捨てである点がちょっといい。ZILデバイスを失うと、そのホライズン以降の書き込みを失うけど、全体のアレイを失うわけじゃない。次のステップは「メタデータ」デバイスを構築することで、ファイルシステムのメタデータを保存するけどデータは保存しない。これはext4ジャーナルと同じように危険で、メタデータを失うと全てを失うことになる。どちらも大幅なスピードアップになる。大きな書き込みをするとき、たくさんのスピニングラストだけではSSD ZILなしではフルスループットを達成できない。私の8+2アレイはほぼ2ギガビット書き込めるけど、ZILなしではひどい（単一のドライブの速度程度）。同様に、メタデータデバイスはファイルシステム全体をSSDのようにスナッピーに感じさせることができるけど、十分なキャッシュスペースがあれば必要ない。ZFSはそれを好むから、メタデータがキャッシュSSDに収まるなら、大部分は常にロードされた状態になるよ。

└

しかし、SSDが故障すると、それがいくつかのディスクからのデータ損失の根本原因になる（リードキャッシュとは違って）。理論的には、ジャーナルのコピーをメモリに保持することで、このリスクを大幅に減らせるけど、ディスクの損失と電源の喪失が数秒以内に起こらない限り、壊れないんだ。でも、利用可能なツールがそれを適切に行えるかは分からないな。

└

ツインSSDとRAID 1。

オプテインドライブが懐かしいな。

└

Aliexpressでまだ買えるうちに一つゲットしとこうかな。

RAID1のことを忘れがちなのは、これは壊滅的なディスク故障からしか守れないってこと。つまり、RAIDが保護するためにはドライブが死んでないといけないんだよね。問題は、データが壊れ始めると、RAIDはそれを知る手段がないこと。そうなると、健康なドライブのデータも壊れちゃうことがある（壊れたデータが読み込まれて、両方のドライブに書き込まれる）。データのコピーが2つあるけど、RAIDはどちらが正しいか判断できないから、基本的にはコインを投げてどちらかを選ぶことになる。たとえファイルシステムがその内容が意味をなさないことを知っていても。これが、ZFSやBtrfsのようなファイルシステムの最大の利点で、RAIDを自分で管理していて、チェックサムがあって、どのコピーが有効かを知っていて、復旧できるんだ。だから、1つのドライブは健康そうに見えてもデータを壊しているから、交換した方がいいよって教えてくれる。

└

2011年頃にその体験をしたことがあるよ。MinecraftサーバーをRAID1のボックスでホストしてたんだ。面白いのは、1時間ごとにマップをPNGファイルにレンダリングするcronジョブを動かしてたこと。ある時、友達からマップに穴が開いてるって聞かれたんだよね。当時、Minecraftはマップの16x16チャンクを個別のgzippedファイルに保存してたんだ。RAID1が悪いドライブからチャンクを読み込もうとすると、解凍できなかったんだよ。それがレンダラーに起こると、マップに穴ができちゃうし、ゲームサーバーに起こるとチャンクが再生成されて、古いものが両方のドライブ、健康な方も上書きされちゃう。幸いなことに、確かそれはランダムな地形でしか起こらなかったから、誰かが家の半分を失うことはなかったけどね。

└

LVMを使うと、dm-integrityターゲットを使ってデータの破損を検出できるよ。

└

自分の高級RAID5カードがディスクアクセスにDMAを使ってて、自前のメモリを持ってないって知った時は驚いたよ。本当にバカな設計だよね。電源の問題でマシンの最後のメモリスティックが壊れちゃって、クリーンに立ち上がるけど負荷がかかるとディスクの破損を報告するようになった。ディスクは問題なかったのに、メモリが壊れてた。メモリアナライザーを使うまで、そのクソ配列を三回も再構築したよ。

QNAP NASシステムのティアリングの技術について知っている人いる？SSD RAID 1をRAID 10の前に使ってるけど、すごくうまく機能してる。個人的には、キャッシングよりも柔軟なティアリングが多くのシステムにとって良いと思う。ユーザーに古いデータと変化するデータを分けるのは結構難しいから。完璧である必要はないことが多いし。

Hacker Newsで議論の続きを見る

ハクソク