先介绍一下実践の背景：
私はずっと Synology から NAS システムに移行し、Synology のような NAS オペレーティングシステムが使いにくいわけではありません。実際には、あまりにも便利すぎて Linux 関連のコマンド操作を学ぶことができないため、家庭用メディアストリーミングを始めてから、常に PVE をベースにして自分自身のメディアストリーミングを手動で構築しています。これは、自分自身を Linux の操作に学習させるための方法です。
したがって、NAS キャッシュも PVE オペレーティングシステムに構築されています。
2023 年下半期、NAS を始めてから、ディスクスペースが足りないことに気付きました。速度の観点から、最初は RAID10 のソリューションを使用してディスクを仮想マシンに追加しました。当時、qb と NAS 管理システムは分離されており、NFS マウントを使用してダウンロードディレクトリをダウンローダーとメディア管理ツールの両方が監視するため、HDD ディスクの書き込み速度の影響を実際に感じませんでした。しかし、2024 年の春になって、仕事の転勤のため、引っ越し後はもう 1 ヶ月以上シードをしていないので、この機会に NAS を再整理しようと考えました。そして、再びトラブルシューティングの旅が始まりました。
1、システムベースの再構築#
PVE ベースは保持し、以前は qb を個別の仮想マシンにデプロイしていましたが、NAS 管理ツール、字幕ツール、補完ツールをすべて k8s 環境に統合してデプロイしました。今、すべてのツールを 1 つの仮想マシンに統合しました。そのため、6C64G の Rocky Linux をメディアライブラリディレクトリとして作成し、統合後の 30T のメカニカルハードディスクスペースを Rocky に割り当てました。
ディスクスペースの統合には LVM 論理ボリュームの方法を使用しました。
LVM 論理ボリュームとは何ですか？
LVM（Logical Volume Management）は、Linux 環境でディスクドライブや類似のストレージデバイスを管理するための方法です。LVM を使用すると、ストレージスペースをより柔軟に管理できます。論理ボリュームは、LVM の管理下で作成および使用されるストレージスペースの単位です。
LVM のコンポーネントには、物理ボリューム（PV）、ボリュームグループ（VG）、論理ボリューム（LV）があります。
LVM はディスクサイズを動的に調整することができ、スナップショット機能をサポートしています。
LVM の方法は RAID10 と比較して、データの冗長性のために半分のディスクスペースを犠牲にする必要はありませんが、RAID10 の高性能を失っています。
1.1 LVM 論理ボリュームの構築#
> root@ubuntu:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdc 8:32 0 3.6T 0 disk
└─lvgroup-lv29_corig 253:12 0 29.1T 0 lvm
└─lvgroup-lv29 253:4 0 29.1T 0 lvm /mnt/lv29
sdd 8:48 0 3.6T 0 disk
└─lvgroup-lv29_corig 253:12 0 29.1T 0 lvm
└─lvgroup-lv29 253:4 0 29.1T 0 lvm /mnt/lv29
sde 8:64 0 3.6T 0 disk
sdf 8:80 0 3.6T 0 disk
└─lvgroup-lv29_corig 253:12 0 29.1T 0 lvm
└─lvgroup-lv29 253:4 0 29.1T 0 lvm /mnt/lv29
sdh 8:112 0 14.6T 0 disk
└─lvgroup-lv29_corig 253:12 0 29.1T 0 lvm
└─lvgroup-lv29 253:4 0 29.1T 0 lvm /mnt/lv29
sdi 8:128 0 3.6T 0 disk
└─lvgroup-lv29_corig 253:12 0 29.1T 0 lvm
└─lvgroup-lv29 253:4 0 29.1T 0 lvm /mnt/lv29
sdj 8:144 0 7.3T 0 disk
└─sdj1 8:145 0 7.3T 0 part
上記のように、sdc、sdd、sdf、sdh、sdi、sdj の 6 つのディスクが組み合わさって 29.1T の lv29 論理ディスクが作成されました。
具体的な操作は以下の通りです：
## pv物理ボリュームの作成
> pvcreate /dev/sdc /dev/sdd /dev/sdf /dev/sdh /dev/sdi /dev/sdj
## lvgroupボリュームグループの作成
> vgcreate lvgroup /dev/sdc /dev/sdd /dev/sdf /dev/sdh /dev/sdi /dev/sdj
## lv論理ボリュームの作成し、すべてのディスクスペースをlvgroupボリュームグループに割り当てる
> lvcreate -n lv29 -l 100%VG lvgroup
作成後、論理ボリュームは通常のディスクと同様にシステムに存在し、次にファイルシステムの形式を設定し、マウントポイントを設定してから正常に使用できます。
## ext4ファイルシステムを作成するためのフォーマット
> mkfs.ext4 /dev/lvgroup/lv29
## マウントポイントの作成
> mkdir -p /mnt/media
## 論理ボリュームのマウント
> mount /dev/lvgroup/lv29 /mnt/media
## 起動時に自動マウント
> echo "/dev/lvgroup/lv29 /mnt/media ext4 defaults 0 0" | tee -a /etc/fstab
1.2 PVE でディスクを Linux にマウントする#
仮想マシンのハードウェアオプションで新しく作成した lvgroup 論理ボリュームを追加し、利用可能なスペースを入力することでディスクの追加が完了します。
2、LVM キャッシュレイヤー#
ディスクのマウントと使用後、キャッシュレイヤーのない欠点が徐々に現れてきました。たとえば、NAS 管理システムでシードファイルを追加してダウンロードする場合、qb が複数のダウンロードタスクを管理している間に、NAS 管理システムがメディアを検索したり他の操作を行ったりすると、qb がディスクに書き込み操作を行っているため、システムがフリーズすることがあります。
ダウンロードされたファイルは HDD に直接書き込まれ、最初のキャッシュハードウェアとしてメモリを使用します。これは、ファイルの書き込み効率を向上させ、ディスクへの書き込み操作を減らすためです。
メモリのサイズは GB 単位のサイズしかないため、ファイルブロックはディスクへの書き込みプロセスを経て、ディスクの IO（ページキャッシュ）を介してキャッシュされます。大量のファイルや複数のダウンロードコンテンツが同時に HDD 論理ボリュームに書き込み操作を実行する場合、ディスクの IO がすぐにいっぱいになります。NAS 管理ツールでは、ダウンロードディレクトリの監視はディスクの読み取り操作です。HDD に大量のファイルが書き込まれている場合に使用されるため、読み取りと書き込みが同時にディスクの IO を使用すると、ディスクの IO が詰まる状況が発生し、使用体験に大きな影響を与えます。具体的には、3 つ以上のダウンロードタスクが存在する場合、NAS 管理ツールは非常に大きな遅延が発生し、ページのリフレッシュに 5〜30 秒かかります。これは、ディスクの IO とメモリの両方が非常に混雑しているためです。
そのため、LVM キャッシュレイヤーのメカニズムを導入し、IOPS の高い sdd の特性を利用して、HDD の容易な IO ブロックを緩和する必要があります。具体的には、ユーザーがダウンロードタスクを実行すると、ダウンロードされるファイルブロックはまずメモリに入り、次に LVM キャッシュ領域（sdd）に書き込まれ、最後に HDD に書き込まれます。
2.1 既存の LVM 論理ボリュームにキャッシュレイヤーを追加する#
私は 2 つの SSD ディスク、sdb と sdg を持っており、これらを LVM に追加してキャッシュとして使用する必要があります。LVM のキャッシュレイヤーのキャッシュロジックは LVM 内で自己管理されるため、LVM のキャッシュレイヤーに追加するだけで十分です。
## SSDのための論理ディスクを作成する
pvcreate /dev/sdb /dev/sdg
## ボリュームグループlvgroupに拡張する
vgextend lvgroup /dev/sdb /deb/sdg
## すべてのスペース（現在はSSDのみが空きスペース）をキャッシュプールに追加する
lvcreate --type cache-pool -l 100%FREE -n lv_cache_pool lvgroup
## 既存のキャッシュプールをlv29論理ボリュームにアタッチする
lvconvert --type cache --cachepool lvgroup/lv_cache_pool lvgroup/lv29