先介绍一下実践の背景：
ずっと個人的には 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 の HDD スペースを 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 への読み取り操作が行われるため、大量のファイルが HDD に書き込まれている場合に使用されます。この場合、読み書きが同時にディスクの IO を使用するため、ディスクの IO が詰まる状況が発生し、使用体験に大きな影響を与えます。具体的には、3 つ以上のダウンロードタスクが存在する場合、NAS 管理ツールには非常に大きな遅延が発生し、ページのリフレッシュには 5〜30 秒かかります。これは、この時点でディスクの IO とメモリの両方が非常に混雑しているためです。
そのため、LVM キャッシュレイヤーのメカニズムを導入し、IOPS の高い sdd の特性を利用して、HDD が容易に IO が詰まる現象を緩和することができます。具体的には、ユーザーがダウンロードタスクを実行すると、ダウンロードされるファイルブロックはまずメモリに入り、次に LVM キャッシュ領域（sdd）に書き込まれ、最後に HDD に書き込まれます。
2.1 既存の LVM 論理ボリュームにキャッシュレイヤーを追加する#
私は sdb と sdg の 2 つの SSD ディスクを持っており、これらを 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