Summary ¶

前回の初期化試験で背面にあるリセットボタン3秒押しでの admin アカウントパスワード時に暗号化ボリュームのロックがされず、中身が閲覧できてしまうバグを見つけました。 QNAP にもサポートチケットを切って確認したが仕様ということなので QTS の利用を諦らめた。ため、 TrueNAS Scale のテストと構築を試してみる。

QNAP TS-664 初期化試験

一般家庭でもハードウェアを購入した場合、障害試験や復旧試験をすると思うので実施記録

設計 ¶

弊宅のハードウェアを再掲する。

TrueNAS Scale は ZFS でストレージを構成するため ZFS の構成を調査する

ZFS にはキャッシュ機能が複数あり通常であれば ARC(DRAM) がこれとなる。 ARC は読み書きのキャッシュとして利用され TrueNAS Scale 23.10 時点では RAM 容量の 50% が自動で割り当てられる。

SCALE Hardware Guide

Provides information on system hardware and system minimum requirements. Included information covers CPUs, storage considerations and solutions, media and controllers, device sizing and cooling, SAS expanders, and system memory.

www.truenas.com

書込みキャッシュ ¶

• ZIL/SLOG
  • Pool 設定の Log VDEVs に該当する
  • 設定すると ネットワークまたはアプリーケーションからくる書き込みリクエストを 5秒間キャッシュとして書き込む
  • 書き込み中の電源損失はデータロストになる可能性があるためUPSなどを設置する必要がある
  • 書き込みドライブはミラーを推奨
  • 容量の推奨下記
    • 式: ((<Network Speed>*1000*1000)/8)*5= <必要容量(MB)>

      Network Speed	必要容量(MB)
      1.0Gbps	625
      2.5Gbps	1,562
      10.0Gbps	6,250
      20Gbps	12,500

読込みキャッシュ ¶

• ARC
  • RAM で実施される 読込み/書き込みキャッシュ
  • 搭載 RAM の 50% が標準で使われる
• L2ARC
  • Pool 設定の Cache VDEVs に該当する
  • RAM が 64GB 以下の場合は設定するべきではない
  • L2 キャッシュ ARC に収まらないキャッシュデータを NVMe などの高速ストレージで保持することで読み取り性能を上げる
  • 大事なのはランダム読み取りパフォーマンス
  • 複数 Pool にまたがる L2ARC は作れない(専用で用意する必要がある)
  • 容量は RAM の 1-5倍迄が目安
  • L2ARC のセクターあたり 88byte の RAM が必要
    • 計算式: (((<L2ARC容量>*1024*1024)/4096)*88)/1000=<L2ARC RAM 使用量(MB)>

      L2ARC容量	L2ARC RAM 使用量(MB)
      16GB	360.45
      32GB	720.90
      64GB	1,441.80
      128GB	2,883.58
      240GB	5,406.72
      256GB	5767.19
      480GB	10,813.44
      512GB	11,534.34
      960GB	21,626.88

性能比較 ¶

fio で Disk benchmark を走らせて確認することにする。

Linux で CrystalDiskMark 8 ぽい計測をする

L2ARC は搭載RAM 64GB 以下では非推奨であるが速度が変わるのか確認する。試験方法は TrueNAS Scale 23.10 内蔵の fio に上記記事で書いた fio.txt を使ってベンチをかける。 Data vDevs は 16TB でメーカー公称と弊宅実測で1台あたり 258MB/s は出る。

結論として弊宅の構成では L2ARC の恩恵は微かである。 1GbE=125MB/s, 10GbE=1,250MB/s であることを考えても SLOG まであれば十分である。 SLOG には 調達済みだったため WD Red SN700 500GB を Miror にして利用する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/usr/bin/env bash
set -eu

DESC=${1}
TARGET=/mnt/tank1/tmp

for size in "1GiB" "4GiB" "10GiB"
do
  echo "fio testing... ${size}"
  SIZE=${size} DESC=${DESC} TARGET=${TARGET} fio -f fio.txt --output-format=terse | awk -F ';' '{print $3, ($7+$48) / 1000}'
done

最終的な構成 ¶

最初とあまり変わらないが Data Pool の SLOG として SN700 を利用することにしてあとは構成変更せずに作成することにした。

OS 用は USB フラッシュメモリーで妥協予定だったが、 TrueNAS Scale の推奨要件で SSD が推奨されていることと USB フラッシュメモリーは非推奨い現在なっているため USB SSD を購入した。購入前の下調べで TBW や MTBF/MTTR 系の情報が一切なく大丈夫なのかと思ったが通常の USB メモリーより高耐久なのは間違えなさそうなためこちらにすることにした。スペースの問題もあるため飛び出し 17mm は魅力的であった。

バッファロー SSD 外付け 250GB 極小 コンパクト ポータブル PS5 / PS4 対応 (メーカー動作確認済) USB3.2 Gen2 読込速度 600MB/s ブラック エコパッケージ SSD-PST250U3BA/N

amazon.co.jp

実際現物を確認すると、下記の様であったが S.M.A.R.T に対応していて一応健康状態を確認できそうである。ので監視をしっかり仕込めば実用の範囲内に見えるのでこれを OS Disk として利用していく。 TrueNAS Scale は事前の情報で設定情報さえ取ってあれば再インストールで修復することもできると聴いてるのでそれが可能なら設定を自動でバックアップするか、大きめの変更を実施したさいに手動でバックアップを作成して別のストレージに保存すれば OS Disk 障害にも対応できそうである。