最初に

APC SMT500JにWindowsServerとQNAP NASを2台同時接続できる記事を紹介しましたが
今回はQNAP NAS TS-873のみを接続した状態でどの程度の負荷になるかを紹介します

APC SMT500J

APC Smart-UPS 500 LCD 100V SMT500J
500VAモデル

QNAP NASとの接続は汎用のUSBタイプBとUSBタイプAの変換ケーブルを使用

QNAP TS-873

メモリは16GBx4枚で64GB化済
HDDはWD Blueの5400rpm 4TBを8台フルに搭載
QTSバージョンは4.4.1.1146
LANは4本GbE接続

以前紹介した消費電力記事では7200rpm物のHDDを使用していたので
今回使用しているHDDとは異なります

ファイル転送などはせずアイドル状態での負荷になります

UPS上での表示

UPS本体にある液晶画面でのLoad値は15～18%を推移

QNAP上での表示

QTSのコントロールパネル内にあるシステム -> 外部デバイス -> UPS

今回の環境では推定保護時間は1時間16分でした

最後に

推定保護時間は実際の負荷から計算される為
使用しているHDDやバックグラウンド処理で数値が変化しますし
アイドル状態で1時間16分なだけで少しでも負荷があれば当然1時間16分も持ちません

よって各環境ごとにNASをセットアップしてからLoad値と推定保護時間を確認後
シャットダウンまでの時間を設定することになります

UPSへの電源供給がなくなった場合はQNAP NASへも通知されるので
QTS上にある通知センターでメール通知などを設定していれば通知を受信できます
（当然ながらハブやルータなどメールサーバまでの経路が停電せずに動作している前提です）

NAS 名: NAS
重大度: Warning
日付/時刻: 2020/01/01 12:01:02

アプリ名: 外部デバイス
カテゴリー: UPS
メッセージ: [外部デバイス] UPS の電力損失を検出しました。5 分後にNASをシャットダウンします。

メールはこんな感じです

最初に

検証に使用したQTSは4.4.1.1117です

今回は以下の条件下で発生する面倒な仕様を紹介
・暗号化ボリュームを使っている
・暗号化キーをNAS本体に保存しない
・スナップショット機能を使用

今回のネタはどちらかというと複数人利用を想定した話です

暗号化ボリュームについて

QNAPの場合、暗号化ボリュームにアクセスする場合に使う暗号化キーの運用は
暗号化キーをNAS本体に保存するか
起動毎に手動で暗号化パスワードか暗号化キーファイルを使ってロック解除の3択

NAS本体に保存

NAS本体に保存すると暗号化処理コスト以外は通常ボリュームと変わりなく
NAS起動時のロック解除を自動で処理してくれたり
今回の記事ネタであるスナップショット運用でも影響がなく簡単で便利だが
肝心のデータ保護についてはそのまま運用してしまうと
盗む目的がデータであろうと金目のものであろうとNAS丸ごと盗むのが正解なのに
わざわざNAS本体は盗らず、ご丁寧にHDDだけ盗まれるという
レアケースでしかデータを守ることができない

NAS本体を盗んでも管理者ユーザのパスワードもわからないからログインできないし
DHCPじゃないしSMBのゲストアクセスを無効にしているから大丈夫と思いきや
QNAPの背面にはコンフィギュレーションリセットスイッチ（リセットスイッチ）があって
このリセットスイッチを使って基本システムのリセット（3秒押し）をすれば
adminパスワードとネットワーク設定がリセットされる機能がある
もちろんこの3秒リセットは保存データには影響しないし
adminユーザを無効にしていても有効になる

他社のNASならこのリセット機能が働くと保存された暗号化キーも無効にされて
再度手動で暗号化キーの入力をしないとロック解除できずデータは守られるが
なぜかQNAPは本体に保存した暗号化キーは削除されずに残っており
パスワードがリセットされたadminでログインすれば
暗号化ボリュームも自動でロック解除されている状態となる
（QTS 4.4.1.1117で個人的にも試して確認済）

この問題はたまにフォーラムで指摘されてはいるものの未だ放置されているのが現状

というわけでどうしても暗号化キーを保存したいけどデータ保護したいという場合は
「コンフィギュレーションリセットスイッチ無効」の設定が必須となる
ただ何か問題が発生した場合でも当然リセットスイッチは使えないので
デメリットも理解した上で設定する必要がある

暗号化パスワード

暗号化パスワードはボリューム作成時に入力した文字列で暗号化キーそのもの
暗記して手動入力が最強ではあるが
長期的な運用と暗号強度を考慮した桁数だとなかなか現実的には難しい
txtからコピペするぐらいならキーファイルで済む話なので
現実的にはこれで運用するメリットは少ない

暗号化キーファイル

QNAPで暗号化ボリュームをまともに運用しようと思うとこれしかないのが
暗号化キーファイルでの運用でボリューム作成後にダウンロードできるようになっている
キーファイル自体はkey拡張子で中身は512桁の文字列で構成されたテキストファイル
決して暗号化パスワードが裸で保存された単純なテキストファイルというわけではない
デメリットはファイルの保管場所

今回は一番多いであろう暗号化キーファイルでの運用を前提に説明してますが
どの方法にしろ一度暗号化キーを使ってマウントすれば
再度ボリュームロックするかNASを再起動するまでは
Windows共有などでも読み書きが可能で
通常ボリュームと同様の扱いになると思いがちですがスナップショット周りだけは違います

スナップショットマネージャーの動作

改めて書いておきますがこれは暗号化キーをNAS本体に保存している場合は
保存された暗号化キーを使って自動で処理されますのでこの状態にはなりません

では本題ですが暗号化ボリュームを暗号化キーファイルでロック解除して
ボリュームが「準備完了」のステータスの状態になった状態で
スナップショットマネージャーを開くとどうなるのか？
それがこちらです

左上でボリューム自体は「準備完了」になっていてロック解除済なのが確認できますが
スナップショットデータは別途ロック解除が必要になります

「ロック解除>>」というリンクを選択すると
ボリュームをロック解除する時と同じような画面が出ます

暗号化キーファイルの場合はこちら

暗号化キーの保存はボリュームと同様にNAS本体に保存するオプションです

日本語サイズに入力フォームが合ってないのか文字が被ってますが
「すべてのスナップショットのロック解除」というオプションがあり
これを選択しない場合は各スナップショットデータごとにロック解除が必要になります

ここで気になるのは「すべてのスナップショットのロック解除」というオプションを使って
これを起動後に1回しておけばボリュームのロック解除と同様に
全スナップショットデータがロック解除されるのではないか？という疑問ですが答えは
ロック解除以前に撮られたスナップショットは全て解除されるが
ロック解除以後に撮られたスナップショットはロックされたままになります
つまり最近のスナップショットを使いたければロック解除の操作が必須なのです

暗号化キーファイルを使用した時点に存在するデータは全てロック解除されるという仕様は
NASを再起動した後の暗号化ボリュームのロック解除でも同様の処理になっていて
先ほどの１枚目の画像でロック状態になっている18時21分のスナップショットも
再起動後に暗号化ボリュームを暗号化キーファイルを使用してロック解除すると
自動で見えるようになっています

しかし再起動後に新しく撮った18時38分のスナップショットデータはロック状態になります

次はこの仕様がスナップショットマネージャー以外にも影響しているという話

スナップショットを利用する他の機能について

ロック解除しないとスナップショットのデータが閲覧できないということは
スナップショットに関係する全てのアプリに影響します

例えばスナップショットマネージャーで見なくても
Windowsファイル共有にて@Recently-Snapshotフォルダから
スナップショットを閲覧できる機能もありますがこれも影響します

動作としては@Recently-Snapshotフォルダ自体は機能を有効にしていれば配置されますが
@Recently-Snapshotの中にはロック解除したスナップショットデータのみ表示されるので
NAS起動後に何もしなければ@Recently-Snapshotの中は
ボリュームロック解除した時点までのスナップショットデータのみ表示されて
新しいスナップショットデータはスナップショットマネージャーでロック解除するか
再度ボリュームをロック解除するまでは表示されません

他にも「Windowsの[以前のバージョン]」機能や
File Stationのスナップショットフォルダも同様にロック解除しないとリストに表示されません

最後に

スナップショットをよく使う用途であれば暗号化を有効にすると
なかなか面倒な仕様に仕上がっていますので注意が必要です

新しいスナップショットはロック解除しないと中身を閲覧できず
毎度、暗号化キーファイルが必要ということは
暗号化キーファイルの使用頻度も上がり暗号化キーファイル自体の管理も
NAS起動時だけ保管場所から取り出せばいいという訳にもいかなくなります

理想というか普通はボリュームのロック解除中はオンメモリで暗号化キーを保管して
新しいスナップショットデータも自動でロック解除して欲しいところ

暗号化キー周りの作りは他の記事でも触れてますが
暗号化キー変更の制限や物理キーが作成できなかったりと
他社のNASを使ったことがあるとどうしても不便と感じるのが本音です

最初に

QNAP TS-873-4G
メモリを64GB化済

Amazon | QNAP(キューナップ) TS-873 クアッドコア2.1 GHz CPU 4GBメモリ 8ベイ DTCP-IP/DLNA対応
https://amzn.to/34uq7oC

WD WD40EFRX-RT2

Amazon | WD HDD 内蔵ハードディスク 3.5インチ 4TB WD Red NAS用 WD40EFRX-RT2 5400rpm 3年保証
https://amzn.to/2q3yQ2t

8台検証したST1000DM010は7200rpmのHDDだったので
5400rpmのHDDで検証する為、WD40EFRX-RT2を使用します

こちらは手元に4台しかなかったので4台までの検証を行います

IntelliParkを無効化

WDのHDDを買ってまずすることはもちろんIntelliParkを無効化です

NASに突っ込む前に余ってるPCにWD40EFRX-RT2を接続して
Arch LinuxのUSBブートで起動

idle3-toolsをインストール
# pacman -Syy idle3-tools

無効化したいWD40EFRX-RT2のデバイス名確認
# fdisk -l

現在のIntelliPark設定状態を確認（sdaの部分をfdiskの結果に合わせる）
# idle3ctl -g /dev/sda
Idle3 timer set to 138 (0x8a)

IntelliParkを無効化する
# idle3ctl -d /dev/sda
Idle3 timer disabled

シャットダウンで終了
# shutdown -h now

この時点で設定されていますが
念のため確認したい場合は再度PCを起動して設定状態を確認します

WD40EFRX-RT2のIntelliPark設定値は初期値だと300秒
# idle3ctl -g /dev/sda
Idle3 timer set to 138 (0x8a)

ちなみにWD Blueの場合は初期値が8秒
Idle3 timer set to 80 (0x50)

WD Redの場合はBlueより長めに設定されているので
Load_Cycle_Countカウントはかなり減るとは思うが
ここを調整してきてる辺りWDもわざと嫌がらせしてるんじゃないのかと思いつつ
そもそも不要な機能なので無効化しました

WD40EFRX-RT2単体で計測

NASではなくPCへ接続して直接計測

CrystalDiskMark 7.0.0fの結果

TS-873に入れて計測

QTSのバージョンは4.4.1.1117

QTS上でのWD40EFRX-RT2の実認識容量は3.64TB（4TB）

システムボリュームは別のディスクへ既に作成済

NASローカル計測の計測方法については以前の記事と同じですので
そちらをご覧ください

TS-873でのローカル速度計測 | fefcc.net
https://fefcc.net/archives/886

HDD1台 RAIDなし

ストレージプール作成の想定容量

想定空き容量：3.63TB
想定予約済みスペース：103.77GB
想定未割り当てスペース：3.53TB

実際に構築した状態

空き容量：3.63TB
予約済みスペース：103.73GB
未割り当てスペース：3.53TB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV3_DATA/test/fio-cdm /share/CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    175.824|    171.037|
| 512K |     52.054|    107.653|
|   4K |      0.516|      1.849|
|4KQD32|      1.776|      1.800|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV3_DATA/test/fio-cdm /share/CE_CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    168.727|    161.744|
| 512K |     50.167|     96.613|
|   4K |      0.524|      1.855|
|4KQD32|      1.819|      1.854|

HDD2台 RAID1

ストレージプール作成の想定容量

想定空き容量：3.63TB
想定予約済みスペース：103.77GB
想定未割り当てスペース：3.53TB

実際に構築した状態

空き容量：3.63TB
予約済みスペース：103.73GB
未割り当てスペース：3.53TB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV3_DATA/test/fio-cdm /share/CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    169.762|    163.552|
| 512K |     52.600|     96.060|
|   4K |      0.527|      1.511|
|4KQD32|      3.259|      1.768|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV3_DATA/test/fio-cdm /share/CE_CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    161.974|    148.406|
| 512K |     51.148|     90.812|
|   4K |      0.520|      1.497|
|4KQD32|      3.276|      1.788|

HDD3台 RAID5

ストレージプール作成の想定容量

想定空き容量：7.26TB
想定予約済みスペース：140.94GB
想定未割り当てスペース：7.12TB

実際に構築した状態

空き容量：7.26TB
予約済みスペース：140.89GB
未割り当てスペース：7.12TB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV3_DATA/test/fio-cdm /share/CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    275.788|    154.193|
| 512K |     54.376|     39.169|
|   4K |      0.575|      0.636|
|4KQD32|      4.795|      1.754|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV3_DATA/test/fio-cdm /share/CE_CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    264.189|     80.897|
| 512K |     51.515|     35.444|
|   4K |      0.564|      0.616|
|4KQD32|      4.967|      1.703|

HDD4台 RAID5

ストレージプール作成の想定容量

想定空き容量：10.89TB
想定予約済みスペース：178.11GB
想定未割り当てスペース：10.72TB

実際に構築した状態

空き容量：10.89TB
予約済みスペース：178.05GB
未割り当てスペース：10.71TB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV3_DATA/test/fio-cdm /share/CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    205.457|     74.527|
| 512K |     56.400|     34.311|
|   4K |      0.613|      0.668|
|4KQD32|      6.332|      1.594|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV3_DATA/test/fio-cdm /share/CE_CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    194.123|     61.380|
| 512K |     53.501|     30.708|
|   4K |      0.607|      0.651|
|4KQD32|      6.254|      1.608|

HDD4台 RAID6

ストレージプール作成の想定容量

想定空き容量：7.26TB
想定予約済みスペース：140.94GB
想定未割り当てスペース：7.12TB

実際に構築した状態

空き容量：7.26TB
予約済みスペース：140.89GB
未割り当てスペース：7.12TB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV3_DATA/test/fio-cdm /share/CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    201.614|    149.839|
| 512K |     52.678|     36.516|
|   4K |      0.583|      0.578|
|4KQD32|      5.847|      1.604|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV3_DATA/test/fio-cdm /share/CE_CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    183.021|     77.559|
| 512K |     52.117|     33.907|
|   4K |      0.571|      0.571|
|4KQD32|      5.859|      1.621|

HDD4台 RAID10

ストレージプール作成の想定容量

想定空き容量：7.26TB
想定予約済みスペース：140.94GB
想定未割り当てスペース：7.12TB

実際に構築した状態

空き容量：7.26TB
予約済みスペース：140.89GB
未割り当てスペース：7.12TB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV3_DATA/test/fio-cdm /share/CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    344.434|    308.248|
| 512K |     54.751|    166.721|
|   4K |      0.566|      2.529|
|4KQD32|      5.720|      3.406|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV3_DATA/test/fio-cdm /share/CE_CACHEDEV3_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    342.475|    217.826|
| 512K |     54.877|    138.006|
|   4K |      0.563|      2.527|
|4KQD32|      5.727|      3.464|

まとめ

今回もWindowsからの計測はGbE上限値なのであまり意味はないですが
SSD記事と同様に記録用として丸ごと掲載しました

ローカル計測結果については
ST1000DM010より高速になってたり逆に数値落ちすぎじゃない？と思う場面があり
自分でみても裏で何か動いてるのか？と確認したぐらい謎でしたが
ちゃんと前回同様の条件として10回10秒間隔で計測したので
結果は結果としてそのまま掲載しました

ST1000DM010でのローカル計測記事でも書きましたが
fio-cdm計測は50前後の誤差が平気で発生してしまうので
そのつもりで参考にしてください

LAN経由だとよっぽどの一気に大容量を流し込まなければ
メモリキャッシュが機能して転送速度は安定するので
実用上ではあまり気にすることはないと思います

最初に

QNAP TS-873-4G
メモリを64GB化済

Amazon | QNAP(キューナップ) TS-873 クアッドコア2.1 GHz CPU 4GBメモリ 8ベイ DTCP-IP/DLNA対応
https://amzn.to/34uq7oC

Crucial CT250MX500SSD1/JP

Amazon | Crucial SSD 250GB 内蔵2.5インチ 7mm MX500 (9.5mmアダプター付) CT250MX500SSD1/JP
http://amzn.to/2Gm7bNc

SSDを入れてみるとどのくらいのパフォーマンスがあるのか
手元にCT250MX500SSD1/JPが2台あったので入れてみました

CT250MX500SSD1/JPについては以前の記事で紹介してますが
購入時期が違ってFWも違うので改めて計測してます

crucial MX500 CT250MX500SSD1/JPを計測 | fefcc.net
https://fefcc.net/archives/605

CT250MX500SSD1/JP単体で計測

NASではなくPCへ接続して直接計測
FWはM3CR023

CrystalDiskMark 7.0.0fの結果

TS-873に入れて計測

QTSのバージョンは4.4.1.1117

QTS上でのCT250MX500SSD1/JPの実認識容量は232.89GB（250GB）

システムボリュームは別のディスクへ既に作成済

SSD使用時に選択できるオーバープロビジョンは使用してません

NASローカル計測の計測方法については以前の記事と同じですので
そちらをご覧ください

TS-873でのローカル速度計測 | fefcc.net
https://fefcc.net/archives/886

SSD1台 RAIDなし

ストレージプール作成の想定容量

想定空き容量：223.39GB
想定予約済みスペース：68.83GB
想定未割り当てスペース：154.56GB

実際に構築した状態

空き容量：223.39GB
予約済みスペース：68.79GB
未割り当てスペース：154.59GB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV4_DATA/test/fio-cdm /share/CACHEDEV4_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    342.590|    292.990|
| 512K |    308.992|    271.330|
|   4K |     32.162|     68.804|
|4KQD32|    208.003|    183.578|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV4_DATA/test/fio-cdm /share/CE_CACHEDEV4_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    302.422|    218.523|
| 512K |    242.424|    165.776|
|   4K |     32.806|     53.214|
|4KQD32|    195.569|    181.143|

SSD2台 RAID1

ストレージプール作成の想定容量

想定空き容量：223.39GB
想定予約済みスペース：68.83GB
想定未割り当てスペース：154.56GB

実際に構築した状態

空き容量：223.39GB
予約済みスペース：68.79GB
未割り当てスペース：154.59GB

非暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CACHEDEV4_DATA/test/fio-cdm /share/CACHEDEV4_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    376.609|    285.396|
| 512K |    301.798|    262.161|
|   4K |     33.021|     64.639|
|4KQD32|    230.112|    144.368|

暗号化シックボリューム

CrystalDiskMark 7.0.0fを使ってGbE経由で計測した結果

ローカル計測結果

[~] # /share/CE_CACHEDEV4_DATA/test/fio-cdm /share/CE_CACHEDEV4_DATA/test
|      | Read(MB/s)|Write(MB/s)|
|------|-----------|-----------|
|  Seq |    319.202|    216.720|
| 512K |    234.755|    166.180|
|   4K |     32.782|     50.887|
|4KQD32|    207.036|    148.967|

まとめ

基本的にはキャッシュ無効になって素のパフォーマンスが確認できる
ローカル計測結果を参考に見てもらえればと思います
Windowsからの計測もGbE上限値ですが一応、記録の為掲載しておきました

GbE環境の場合、通信経路がボトルネックなので
HDD・SSDともに実際のパフォーマンスにほぼ変わりはないですが
メモリが少ない等でキャッシュ溢れが多い環境であれば
素のパフォーマンスのおかげでランダムアクセスが快適になります

最後に

SSDをRAIDで使用する場合の注意点ですが
RAIDの仕組み上、全ディスクがほぼ同量の書き込み量になるので
一定の書き込み量で寿命を迎えるSSDとはどうしても相性がよくありません
（特にRAID6を選択するメリットがHDDより減る）

もちろん使い方や何年ぐらい使う予定なのか次第で
倉庫的な書き込みが少ない環境やTBWが元々多いSSDであれば全く気にする必要はなし

仮想マシン用などで書き込みが多い環境や
TBWの少ないQLC SSDを導入する場合だけ注意が必要

事前にこの問題があることを利用者がわかっていれば
ハードな使い方をする環境であっても
S.M.A.R.T.で総書き込み量を確認してTBWに到達する前に交換すれば
簡単に対処可能ですので致命的な問題ではありません

S.M.A.R.T.で「残り寿命」を提供しているSSDであれば
QNAPの場合はディスク情報にて「SSD推定残り寿命」が表示されます

その他情報のリンク先はヘルプセンターになっていて以下の説明文が表示されます

Synologyでも同様にHDD/SSD -> 健康状態に「想定寿命」として表示されています

Synologyの場合は更になる対処法として交換のタイミングを1台だけずらすことが可能な
RAID F1という選択肢がオールSSD構成のNAS向けに用意されています

RAID F1
SSDとRAID技術がもつ特異性により生じる、負荷が均一に分散することで全ドライブが同時に故障するという傾向をいかに防ぐかが大きな課題です

RAID F1 は、異なるドライブにワークロードを不均一にかけるよう特別に設計されたアルゴリズムでこの問題を軽減し、ストレージプールの耐久性を強化し、データの安全性を高めます。

RAID5をベースに1台だけ負荷を多くかけるだけなので意外とシンプル
RAID5ベースなので3台以上が必要ですが気になる方はRAID F1で検索してみてください

QNAPには今のところ似た機能はないですけどオールSSDのNASが増えてきたので
Synologyと同じく倉庫以外で利用するような上位機種に向けて
何らかの形でこの問題に対処してくるのではないかと思ってます

最初に

現在はTS-873をメインに記事化してましたが
他にも何台か管理しているQNAP NASがあるので
TS-873に限定せずQNAP NAS全般に
記事化するほどのネタではないけどメモしておきたい事を
ひらすらこの記事に書いていきますので
記事公開後もこそっと更新すると思います

将来的にアップデートで修正されそうな案件は
QTSバージョンを記載するようにしています

HDDトレイがプラスチック

TS-873もプラスチックですし今のQNAPはほとんどプラスチックになってます
昔のQNAP機種は金属製が当たり前でしたので残念です

TS-873に至ってはHDDトレイの鍵すら省略されてます
QNAPの鍵があっても共通鍵だったりするんですけどね（特にプラの鍵）

QNAPといえばソフトウェアは悪いけどハードウェアは質が良いなんて
言われてましたがどんどんコストダウンされてる印象

ECCメモリ対応機の壁

SynologyはAtomクラスでもECC公式対応しているのですが
QNAPはXeonクラスでしか公式対応はしてません

スナップショット領域の仕様

QTS 4.4.1.1117

前記事で触れてますので詳細はそちらへ

QNAP NASの使用可能容量 | fefcc.net
https://fefcc.net/archives/951

スナップショット領域をユーザにどれくらい使うかを事前に予想させる不親切さ
この時代遅れな仕様はそろそろ何とかしてほしい

システムボリュームの暗号化は想定されていない

QTS 4.4.1.1117

1つ目にボリュームを作ると勝手に割り当てられる
システムボリュームですがこのシステムボリュームを暗号化すると
NAS起動時にWEB管理画面が出ずにSSH接続が必要になるらしいです

QNAPのシステムボリュームを暗号化しているときに，再起動すると管理画面にログインできなくなった場合の対処法 – Qiita
https://qiita.com/masnagam/items/ef6d39bf053a49854dae

私もシステムボリューム作成前でも管理画面は動いていて大丈夫だと思っていたので
実行前にたまたまこの記事を見て助かったパターンでした

ちなみに最近のQNAPはデフォルトでSSH有効だったのですが
QTS 4.4.1.1101 build 20191025からデフォルトでSSH無効に変更されてますので
試す場合は有効に設定するのを忘れずに

USBメモリーを暗号化キーとして使えない

QTS 4.4.1.1117

先ほど紹介した記事内の「暗号化鍵を外部USBメモリーに保存」という項目で
触れられている話と同じです

QNAPのNASはボリュームロック解除の方法でNAS本体に暗号化鍵を保存しない選択肢は
手動のパスワード入力かキーファイルを管理画面でアップロードするかの2択しかありません

手動入力で強度のあるパスワードは現実的ではないしPCにテキスト保存するなら
キーファイルで十分だしって話なので現実的なのはキーファイル運用なんですけど
キーファイル使うならUSBメモリに入れて起動時に読み込んでくれたら
システムボリュームも簡単に暗号化運用出来て楽なのにと思います

この点便利なのがReadyNASで
ReadyNASは起動時に暗号化鍵が入ったUSBメモリーを刺さないとシステム起動自体せず
暗号化鍵が合っていれば自動でシステム起動後にマウントされて利用可能
もちろん起動後はUSBメモリを抜いても問題ないので普段はUSBキーは外して運用し
電源オフでロック状態になるのでNASごと盗もうとコンセント抜いたらロックです

ReadyNASほどのシステムではないですがSynologyも物理キー作成に対応済

ちなみにQNAPで用意されている暗号化鍵をNAS本体に保存する・しないでの効力の違いは
保存しない場合はNASとHDDどちら盗まれてもデータはもちろん閲覧不可能
保存する場合はNASごと盗まれるとデータ閲覧可能でHDDだけ盗まれた場合のみ閲覧不可能

現実的に考えるとラックタイプならまだしも普通の据え置き型の場合は
HDDが盗まれる状況ならNASごと持ち去るでしょう（RAID構成を考慮すると尚更）
メリットとしてはHDDを売却するときにデータ消去作業が不要で楽というぐらいでしょうか
個人的にはNAS本体に暗号化鍵を保存するぐらいなら暗号化しなくてもいい気がします

暗号化キーについてはこちらの記事でも触れています

QNAP NASの暗号化とスナップショットの関係 | fefcc.net
https://fefcc.net/archives/983

データ収集契約はオプトアウト

QTS 4.4.1.1117

初回の管理画面ログイン後に「ストレージ＆スナップショット」ツールが自動で起動し
データ収集契約の同意を求められます

「はい」を選択しないと使えないように勘違いしがちですけど
情報送信したくない場合は「いいえ」でも問題ありません

後から設定変更したい場合は右上にある歯車マークから
グローバル設定 -> ディスク/デバイス -> ディスク分析データをQNAPと共有するをオフ

SSD Profiling Toolも使う際にデータ送信を求められるので
同様に注意してください

QTS4.4系のランダム再起動問題

QTS4.4系で機種に関係なくランダム再起動する問題が
公式フォーラムやredditで数多く報告されていて
QNAP側も問題は把握しているものの
現在最新のQTS 4.4.1.1117 build 20191109でも解決していない模様

現象としては数分・数時間・数日で勝手に再起動されてしまうようで
本当に間隔が環境によって様々でまさにランダム
しかし多くの該当機も4.3系にダウングレードすると大丈夫らしいです

この問題は同じ機種でも発生する場合と発生しない場合があったりで
原因が不明な為、原因究明のために
フォーラムでは4.4系に更新する前に必ずデータをバックアップする旨と共に
再起動問題が発病したらヘルプデスクアプリでサポートチケットを発行するよう
呼びかけられています

私の場合、TS-873は購入直後に4.3系から4.4系にアップデートして
現在は4.4.1.1086と4.4.1.1117でテストしてましたが
（4.4系に上げた後に完全初期化を実行してます）
今のところランダム再起動は一度もありません

使っているアプリも条件なのではないかと言われておりますが
私の場合はSMBとVirtualization Stationしか使っておらず
他サービスは既に無効にしています

今回はテスト中なのでFWも即日アップデート適用しましたが
データを入れて運用開始したらFWもリリース後すぐには入れない方がいいです
QNAP NASは良くも悪くもそんなもんです

myQNAPcloudには気をつけろ

myQNAPcloudは外出先からNASへアクセスする為の機能で
UPnPでルータ超えも自動で楽チン仕様

しかし最近はQNAPを狙ったMuhstikやQSnatchが発生しており利用には注意が必要

この機能の問題は自動で公開される範囲が広すぎる点で
NASがプリインストールで勝手に動かしているサービスまで
サービスが動いていれば利用者の意図せず公開されてしまいます

MuhstikはまさにphpMyAdminにて内部用のはずが
自動で外部にも公開されていて知らぬ間にアタックされたパターンになります

NAS本体のパスワードはしっかり設定していても
（adminのままmyQNAPcloudで公開してたりする冗談みたいなケースもあるらしいですが）
アプリ内や内部でしか使わないユーザ・パスワードは甘いケースが多く
結果、アプリごとに公開されるWEB画面から狙われることになります

myQNAPcloudを使っている場合はまずmyQNAPcloudでの公開サービスを確認し
外出先から使わないサービスは全てmyQNAPcloud経由はオフにしましょう

スナップショットがあると暗号化キーは変更できない

QTS 4.4.1.1117

運用途中に暗号化ボリュームの暗号化キーを変更したくなった場合は
ボリューム管理からアクション→暗号化→変更から新しい暗号化キーに変更できますが
スナップショットのデータが1つでも存在するとこんな表示が出ます

文字通りスナップショットを全て削除しないと
暗号化キーの変更は受け付けない仕様で
これは暗号化キーをNASに保存する・しないに関係なく発生します

スナップショットを使う場合は
最初から暗号化キーを本番用の強度で設定しておき
暗号化キーが漏れてもすぐには変更できないので
暗号化キーの管理には十分注意しましょう

ネットワークごみ箱機能についていろいろ

QTS 4.4.1.1117

要はただのゴミ箱機能ですがネットワークごみ箱を有効にしている共有フォルダには
@Recycleフォルダが追加されます

ファイル名だけセットされているような
中身のない0バイトのファイルはゴミ箱に移動されません

ゴミ箱にあるファイル名と同一ファイル名を消した場合は
1つ目がtest.txt、2つ目はtext.txt[1]という感じでリネームされて保管されます

フォルダ内のファイルを削除した場合はゴミ箱フォルダ内でフォルダが勝手に作成されます
（test/test.txtを消したらゴミ箱内にもtestフォルダが作成される）

ゴミ箱の中で常に「desktop.ini」が見える状態になっている問題
通常のdesktop.iniは隠しファイルとして運用されるので
隠しファイルを表示する設定をしているWindows以外は表示されず意識することはありません
しかしQNAPのゴミ箱フォルダにはなぜか通常ファイルとしてdesktop.iniが配置されるので
残念ながら常に表示されます（QNAP側の実装漏れな気がしますけど）

desktop.iniをWindowsから手動で隠しファイルに設定するともちろん見えなくなりますが
ゴミ箱を空にしたりするとdesktop.iniが再度自動生成される関係でまた元に戻ってしまいます

desktop.iniを間違えて削除してしまった場合でも
上記の理由で勝手に生成されるのですぐに戻したい場合は
管理画面のコンパネから手動でゴミ箱を空にすれば復元されますし
急ぎで無ければ1日経てばゴミ箱チェック時刻の処理で勝手に復元されます
@Recycleはゴミ箱アイコンになっていますが当然設定はdesktop.iniで行われおり
削除するとdesktop.iniが復元されるまでは普通のフォルダアイコンになります

@Recycleフォルダはゴミ箱扱いになっているだけで
ただのフォルダと同じですからWindowsからフォルダごと削除できてしまいます
その場合は何でもいいのでファイルを削除すると@Recycleフォルダが復活します
（ゴミ箱の中身は当然消えます）

最初に

QNAP NASをセットアップして実際にどのくらいの容量が使用できるのか？
NASですから当然気になる点だと思います

QNAPのNAS OSであるQTSには「システム予約スペース」というものがあり
いわばQTS版「天使の取り分」というのが存在します

この記事では実際にどれくらい容量が予約されるのかを紹介していきます

検証環境

検証機はQNAP TS-873-4G

Amazon | QNAP(キューナップ) TS-873 クアッドコア2.1 GHz CPU 4GBメモリ 8ベイ DTCP-IP/DLNA対応
https://amzn.to/34uq7oC

QTSはv4.4.1.1086を使用
HDDはSeagate ST1000DM010 1TB

1TB HDDの実容量は931.51GB
これは本来の「天使の取り分」である1000と1024の違いなんで特に問題なし

QNAPサイト上での情報

システム予約スペースとは

QNAP NAS では、システム予約スペース (Storage Manager では システム予約済み) に次のものが含まれます。

・QNAP RAID の予約スペースに RAID メタデータを格納。各 RAID グループの総容量の 1% が予約され、各グループに対する最大は 150GB です。
・QNAP ストレージ予約スペースには、ストレージ構成データと、NAS を正常に動作させ続けるための余分のスペースが含まれます。大きさは各ストレージプールごとに 約 70 GB 、各スタティックボリュームごとに 20 GB です。
・EXT4 ファイルシステム メタデータ: 大きさは各ユーザー作成ボリュームごとに 1% to 1.5% です。

リリース日: 2017-03-03

ストレージプール

NASのセットアップを始めると最初にストレージプールを作成することになりますが
ストレージプールを作成するだけで早速、システム予約されます

公式の情報が正しければ
まず総容量の1%（上限150GB）をRAID予約スペースとして確保した上で
残り容量を使ってストレージプールを作成

次にそのストレージプールからストレージ予約スペースとして
約70GBがストレージプール内で確保されます
（想定予約済みスペースで表示されるのがこの部分）

つまり1TBHDDの実容量は931.51GBなので
931.51の1%である9.3151GBがRAID予約スペースで使用し
残りの922.1949GBを使ってストレージプールを作成
そのストレージプールの中で70GBをストレージ予約スペースとして確保されます
計算上は（931.51-9.3151）-70=852.1949で約852GBが使用可能容量

RAID作成の想定画面でどの程度になるかを見つつ
実際に構築した結果も一部紹介します

HDD1台

RAIDなし

空き容量：922.01GB
予約済みスペース：75.82GB
未割り当てスペース：846.19GB

計算上は約852GBでしたが
ストレージ予約スペース（約70GB）の部分で75.82GB確保したため
実際にボリューム割り当てできる容量は846.19GBになりました

ちなみにHDD1台なのでRAIDではないのですが
画像内でも新規RAIDグループとして記載されている通り
QTSではディスク数に限らず基本的にはRAIDと同じ扱いになります

純粋なシングルディスクボリュームで作成したい場合は
静的ボリューム作成の方が容量的にはお得になりますが
静的ボリュームについては記事後半で紹介してます

HDD2台

RAID1（実効容量：1台）

空き容量：922.01GB
予約済みスペース：75.82GB
未割り当てスペース：846.19GB

HDD3台

RAID5（実効容量：2台）

空き容量：1.80TB
予約済みスペース：85.03GB
未割り当てスペース：1.72TB

HDD4台

RAID10（実効容量：2台）

空き容量：1.80TB
予約済みスペース：85.03GB
未割り当てスペース：1.72TB

RAID5（実効容量：3台）

空き容量：2.70TB
予約済みスペース：94.25GB
未割り当てスペース：2.61TB

RAID6（実効容量：2台）

空き容量：1.80TB
予約済みスペース：85.03GB
未割り当てスペース：1.72TB

HDD5台

RAID5（実効容量：4台）

空き容量：3.60TB
予約済みスペース：103.46GB
未割り当てスペース：3.50TB

RAID6（実効容量：3台）

空き容量：2.70TB
予約済みスペース：94.25GB
未割り当てスペース：2.61TB

HDD6台

RAID10（実効容量：3台）

空き容量：2.70TB
予約済みスペース：94.25GB
未割り当てスペース：2.61TB

RAID5（実効容量：5台）

空き容量：4.50TB
予約済みスペース：112.68GB
未割り当てスペース：4.39TB

RAID6（実効容量：4台）

空き容量：3.60TB
予約済みスペース：103.46GB
未割り当てスペース：3.50TB

RAID50（実効容量：4台）

空き容量：3.60TB
予約済みスペース：103.46GB
未割り当てスペース：3.50TB

HDD7台

RAID5（実効容量：6台）

空き容量：5.40TB
予約済みスペース：121.90GB
未割り当てスペース：5.28TB

RAID6（実効容量：5台）

空き容量：4.50TB
予約済みスペース：112.68GB
未割り当てスペース：4.39TB

HDD8台

RAID10（実効容量：4台）

空き容量：3.60TB
予約済みスペース：103.46GB
未割り当てスペース：3.50TB

RAID5（実効容量：7台）

空き容量：6.30TB
予約済みスペース：131.11GB
未割り当てスペース：6.17TB

RAID6（実効容量：6台）

空き容量：5.40TB
予約済みスペース：121.90GB
未割り当てスペース：5.28TB

RAID50（実効容量：6台）

空き容量：5.40TB
予約済みスペース：121.90GB
未割り当てスペース：5.28TB

RAID60（実効容量：4台）

空き容量：3.60TB
予約済みスペース：103.46GB
未割り当てスペース：3.50TB

実際に構築した後の容量

HDD1台 RAIDなし

構築前の想定表示
空き容量：922.01GB
予約済みスペース：75.82GB
未割り当てスペース：846.19GB

構築後の表示
空き容量：922.02GB
予約済みスペース：75.78GB
未割り当てスペース：846.23GB

ほぼほぼ想定通りの表示で作成されているのがわかります

HDD8台 RAID10

構築前の想定表示
空き容量：3.60TB
予約済みスペース：103.46GB
未割り当てスペース：3.50TB

構築後の表示
空き容量：3.60TB
予約済みスペース：103.44GB
未割り当てスペース：3.50TB

HDD4台 RAID5

構築前の想定表示
空き容量：2.70TB
予約済みスペース：94.25GB
未割り当てスペース：2.61TB

構築後の表示
空き容量：2.70TB
予約済みスペース：94.22GB
未割り当てスペース：2.61TB

HDD4台 RAID6

構築前の想定表示
空き容量：1.80TB
予約済みスペース：85.03GB
未割り当てスペース：1.72TB

構築後の表示
空き容量：1.80TB
予約済みスペース：85.00GB
未割り当てスペース：1.72TB

まとめ

ほぼ想定容量の表示通りに構築されるので
事前の想定計算は信用できそうです

RAID別で比較しても予約スペースの割合にほとんど変わりはなく
お得なRAID構成というのはないと思います

931.51GBから計算されているのでわかる通り
ここで表示されている未割り当てスペースは既に1024計算になっていて
ここから「天使の取り分」は取られません

ボリューム

ストレージプールを作成したら次にボリュームを作成します

公式情報によるとEXT4ファイルシステムメタデータという名で
ボリュームごとに1～1.5%が使用されます

これは最初から取られる予約スペースではなく
ファイル数など使用状況に応じて増減するようです

ボリューム作成前

システムボリュームになると容量比較が難しくなるので
システムボリュームを別ディスクに作成した後に別途ストレージプールを作成し
そこに検証用のボリュームを作成しました

ちなみにシステムボリュームは最低でも約16GB使われます
システムボリュームについてはこちらの記事をどうぞ

TS-873のシステムボリューム | fefcc.net
https://fefcc.net/archives/895

ボリューム作成画面

まずはボリューム作成画面にて表示される容量を確認します

0GBの場合

下のストレージプール容量に割り当て済みが既に75.78GBと表示されていますが
これはストレージプール作成時に既に確保されている予約されたスペースで
ボリューム作成ごとに75.78GBを取られるわけではありません

先ほどのボリューム作成前のストレージプール管理画面で表示されている通り
75.78GB+846.23GB=922.01GBになります（0.01GBは端数処理の関係だと思われます）

200GBの場合

200GBを設定しても割り当て済みが200GB増えるだけなので
ボリューム容量で設定した容量を超えて確保されることはありません

800GBの場合

最大846.23GBと表示されているのは使用可能容量なので
割り当て済みが846.23GBを超えても問題なく
設定されたアラートの閾値を超えても作成自体は可能です

ちなみに初期設定のままなので赤で表示されているアラート閾値は80%になっています
使用容量が超えるとアラートで教えてくれる機能ですが
不要な場合はストレージプールごとやボリュームごとに設定変更可能です

アイノード別バイト数

ついでの紹介になりますが
下にあるファイルシステムオプションでアイノード別バイト数の設定が可能です
アイノードとカタカナだと違和感がありますがLinux系でおなじみのinodeのことで
初期設定は32Kですが設定値によって最大ファイル数とボリュームサイズが変わります

200GBと800GBの画像を比較してもらうとボリューム容量の入力数値によって
最大ボリュームサイズとファイル・フォルダー最大数が変化しているのがわかります
最大数の表記は1Mが100万なので6Mが600万ファイル、26Mだと2600万ファイル

細かい話をするとアクセス速度や容量使用効率などいろいろあるんですけど
QNAP程度のマシンにそこまで求める人はいないでしょうから
Officeファイルやテキストが相当数あるのなら8Kや16K
動画や画像ファイルとかMB単位のファイルがメインなら16Kか32Kでいいと思います

ボリューム作成後

200GBでボリューム作成した後のストレージプールの状態がこちら
割り当て済みが200GBきっちり増えてます

200GBで作成したボリュームの状態はこちら

容量が196.91GBになっているので3.09GBが予約スペースとして確保されたようです
容量と空きサイズの差は使用済みの60.04MBで合うので無問題
何もファイルは転送してませんがSSHで覗くと管理用ファイルが確認できます

-rw-------  1 admin administrators  6144 2019-11-11 13:39 aquota.user
drwx------  2 admin administrators 16384 2019-11-11 13:39 lost+found/
-rw-r--r--  1 admin administrators    29 2019-11-11 13:39 .qextension

スナップショット領域

スナップショットを使わない人は読み飛ばしてもらって構いませんが
スナップショット機能を使う場合はこの領域を考えてボリュームを作成する必要があります

というのも「ストレージプール＝ボリューム領域＋スナップショット領域」で使う必要があり
ボリューム内にスナップショット領域があるわけではないのです

なのでボリューム作成時にボリューム容量を「最大に設定」ボタンで最大まで割り当てると
警告表示でフリーストレージプール領域がないことを知らせてきます

フリーストレージプール領域というのはボリュームに割り当てていない
未割り当てのストレージプール領域のことで
スナップショット用として割り当てる必要はありませんが
他に用途が限られているので実質的に未割り当て＝スナップショット用になります

実際のスナップショットは差分処理されているので
ファイルの追加・削除・更新の回数や保存期間など様々な条件で
スナップショットに必要な容量は変化するため
（１回あたりのスナップショットは数十MB～GB単位まで変わります）
初めて利用する人はどのくらい容量を消費するかは最初から予測することはできません

というわけで最初から無駄なくボリュームを割り当てるのは不可能であり
実際にある程度の期間、NASを使ってみて
自分の使い方でスナップショットがどの程度の容量を消費するのかが判明してから
ボリュームサイズ調整で無駄スペースを埋める必要があります

保護されたスナップショット領域

一応QNAPとしては「保護されたスナップショット領域」というのを用意していて
スナップショット領域として全体容量の@@%を事前に確保するという形で
ボリュームで意図せず消費しないように防ぐ機能がありますので一応紹介します

こちらが有効化する前のストレージプール（先ほど作成した200GBボリュームの状態）

保護されたスナップショット領域を有効化すると容量設定が出てくる

初期値ではプール領域の20%でストレージプール全領域が922.01GBなので184.40GB
推奨のプルダウンで割合は変更可能でカスタムを選択すればサイズ固定の設定が可能です

ボリューム作成前に「保護されたスナップショット領域」を20%で設定しておくと
深緑の表示で184.40GBが確保されます（75.78GBは予約スペース）

ボリューム作成画面でも最大容量から既に引かれています

QTS上の説明では「保護されたスナップショット領域」の機能について
スナップショットで既にストレージプールを100%消費している状態で
ボリュームサイズを拡張してしまって自動で古いスナップショットが１つ消えてしまった！
というミスを防止する為とありますが実際にはかなりレアケースな事案ですので
普通の人はフリーストレージプールのまま放置でいいと思います

静的ボリューム

あまり使う人はいないと思いますが
HDD1台を外付けHDDのように単体でボリュームを作る場合は
ストレージプールを1台構成で作成する以外に
静的ボリュームを選択する方法もあります

静的ボリューム作成時の想定容量は922.01GB

静的ボリューム作成後に状態確認
ストレージ予約スペースは20GBとの情報でしたが実際には17.97GBで済み
残った実使用可能容量は904.04GB

ストレージプールを作成してから最大容量で割り当てた場合と
静的ボリュームで作成した場合の比較

システムで確保される容量が少ないおかげで約70GBほど違いが出ました

ちなみに画像内のストレージプール3が警告になっている通り
ストレージプールはボリュームに容量を割り当てた時点で容量消費扱いになるので
ストレージプールに容量アラート閾値を設定する場合はそのことを忘れずに

このようにストレージプールでも最大容量までボリュームに割り当てていれば
スナップショットは使えませんが
静的ボリュームは空き容量があってもスナップショット機能は使えませんので
その点だけご注意ください

最後に

1TBHDDの場合はスナップショットを使用しなければ837.94GB
スナップショット用に20%確保すると661.83GB
そこからがシステムボリューム用の16GBを引いたのが使用可能容量です

1TBHDDを使っているレベルでは変わりませんが
システム予約スペースは固定値や上限値があったりするので
実際に使うような数十TBクラスのストレージプールになれば
全体容量から見ると予約スペース使用割合が減ることから
QNAP NASはベイ数が多い方がいろんな意味で効率がいいです

QNAPにおける欠点の1つが今回紹介したスナップショット用の容量確保が必要という仕様で
ボリュームに割り当てたらもうスナップショットに使えないなんて今時ありえません
他社のNASはボリュームを最大限確保しておいてその中の未使用領域を利用する形が多く
容量を無駄にすることのない作りが一般的です
他社はまだext4を使っていた時から実装してますのでBtrfsとか関係ないはずで
そろそろQNAPでもボリューム内で済ませてもらいたいです

プリインストールアプリ

この画面はQTS v4.4.1.1086をインストールして初期化した状態から
不要なアイコンなどを消した状態ですが
「バックアップマネージャ」がプリインストールされているのが
アプリケーションリストとホームアイコンでわかります

バックアップマネージャの画面はこんな感じ
UIからしてもかなり古いのがわかります

このバックアップマネージャのメリットは
QTSに元々組み込まれているのでインストール直後でも使用できて
システムボリュームを不要とする点です

HBS 3

QNAPが現行で開発しているバックアップアプリが「HBS 3」です
アプリ名では「HBS 3 Hybrid Backup Sync」ですが
HBSはHybrid Backup Syncの頭文字なので
QNAPサイトでもあるようにHBS 3が正式みたいです

3.0が出るまでは「Hybrid Backup Sync」という名称でした

HBS 3 | データのバックアップ、復元、同期
https://www.qnap.com/solution/hbs3/ja-jp/

AppCenterの「バックアップ／同期」から「HBS 3 Hybrid Backup Sync」を選択
そのままインストール

HBS 3をインストールするとただ追加されるだけではなく
バックアップマネージャと置換されるので
アプリケーションリストやホームアイコンが
「バックアップマネージャ」→「HBS 3 Hybrid Backup Sync」になります

「HBS 3 Hybrid Backup Sync」の画面はこんな感じ

アプリ容量はv3.0.191016で256.24MB
こちらの表記では旧名称の「Hybrid Backup Sync」のままになってます

QTSの仕様なのでHBS 3に限りませんが
アプリがインストールされているシステムボリュームを削除するとHBS 3は削除されるので
ボリューム構成が決まってからHBS 3を導入しジョブ追加をする流れになります

最後に

機能面での比較はしてませんが
バックアップマネージャで出来ることはHBS 3でもほとんど出来ますので
UIも今風ですし今から設定するならHBS 3を導入をオススメします

ハードウェア概要

NAS

QNAP TS-873-4G
AMD RX-421ND、SODIMM DDR4、4NIC、HDD8ベイ 250W電源

Amazon | QNAP(キューナップ) TS-873 クアッドコア2.1 GHz CPU 4GBメモリ 8ベイ DTCP-IP/DLNA対応
https://amzn.to/34uq7oC

カタログ値
HDDスリープモード：36.43W
通常時：70.26W（8 x 2TB HDD取り付け時[機種記載なし]）

増設用メモリ

CFDのD4N2400CM-16G
SODIMM DDR4-2400 16GB

Amazon | CFD販売 ノートPC用メモリ PC4-19200(DDR4-2400) 16GB×1枚 / 260pin / 無期限保証 / Crucial by Micron / D4N2400CM-16G
https://amzn.to/2NfvXV3

HDD

HDDはSeagate ST1000DM010 1TB 7200rpm 3.5インチ

カタログ値
転送速度：210MB/秒
キャッシュ:64MB
回転数：7200RPM
標準動作モード：5.3W
アイドル時の平均消費電力：4.6W

USB3.0対応HDDケースにST1000DM010を入れて消費電力計測した結果
アイドル：7W
CrystalDiskMark中：9W

計測について

QNAP TS-873の消費電力を様々なパターンでワットチェッカーを使って計測しました

QTSバージョンは4.4.1.1086
室温は23度
ディスクスタンバイモードは無効
基本的に設定は初期値のままで変更した場合は記載しています

QTSの仕様なのかAMD RX-421NDの仕様なのかは不明ですが
TS-873はアイドル状態であっても
常にCPU使用率が数%を推移しており0%になることはまずありません
Intel機であれば数%程度ではそこまで計測値は変わらないのですが
この機種では毎秒の計測値表示が30-38-32-33-40-35-32のように
10W程度上がってすぐ下がる動きを繰り返すような動作をしているので
元々の計測値に大きくブレがあることを前提にご覧ください

記載の数値については先ほどの30-38-32-33-40-35-32の状況だと
30-40W（32W）のように変動幅と私見で落ち着く瞬間が多い数値を記載
（）の中は平均値ではありません（平均だと上に引っ張られるので）

計測結果

HDD本数別

メモリ増設前の2GBx2構成でGbEは1本接続
HDDがない場合はQTSは起動せずに
HDDを入れる旨のWEB画面で停止するのでその画面で計測
HDDありの場合はQTS起動後にある程度落ち着いてから計測

HDDなし：25W
HDD1本：30-38W（32W）
HDD2本：35-45W（37W）
HDD3本：40-55W（44W）
HDD4本：45-59W（50W）
HDD5本：48-63W（51W）
HDD6本：52-69W（55W）
HDD7本：57-73W（60W）
HDD8本：60-79W（65W）

4本と5本の差以外は概ねHDDカタログ値に近い5Wごと上がっています
この辺りは思ったより素直な動きをしているので消費電力を計算しやすいです

8ベイでもSATA拡張ボードが1枚で設計されているおかげで
無駄な消費電力を抑える効果が出ています

CrystalDiskMark計測中

メモリ増設前の2GBx2構成
CrystalDiskMarkで速度計測している状態で計測しました
全て暗号化シックボリューム
計測項目で消費電力が変わるので（）表記はありません

HDD1台：45-56W
HDD2台 RAID1：55-70W
HDD8台 RAID6：73-98W

この計測はディスクの消費電力増よりCPU負荷での消費電力増の割合が高いです

HDD2台の方はCPU使用率最大で40%ぐらいまで一時的に上がりますが
HDD8台 RAID6の方は書き込み速度が落ちるせいか最大で20%ぐらいで済みます
使うディスク性能によってCPU負荷が変わり消費電力も変わります

暗号化の有無でどの程度CPU使用率が違うのかはこちらの記事を参考にしてください

TS-873で大容量ファイルを転送した際のCPU・メモリ消費 | fefcc.net
https://fefcc.net/archives/890

LANポート数別

こちらもメモリ増設前の2GBx2構成
HDDなしの状態は計測値も変動がなく比較しやすいのでGbEの本数を変えて計測しました
リンクは全てGbEです

LAN1本：25W
LAN2本：25-26W
LAN3本：26W
LAN4本：26-27W

大体0.5Wごとに上がっているような感じでした
ちなみにIntel NICです

メモリ枚数別

16GBを4枚増設したついでに枚数別の計測をしました
こちらもLANポート同様にHDDなし状態で計測

メモリ1枚：25W
メモリ2枚：25W
メモリ3枚：26W
メモリ4枚：27W

メモリ2枚と4枚時はデュアルチャンネル構成になります

ちなみに起動時間もメモリ枚数によってチェックシーケンスで時間がかかるせいか
枚数が多いほど時間がかかりました

メモリ1枚：4分35秒
メモリ2枚：4分40秒
メモリ3枚：未計測
メモリ4枚：4分55秒

最後に

ディスクスタンバイモードに入ったときの計測をしたかったのですが
全然入らないので計測できませんでした

最初に

Virtualization StationはQNAP NAS上で使えるKVMで
SynologyでいうとVirtual Machine Manager
VMwareでいうESXiみたいな仮想マシンを動かすソフトウェアです

今回はQNAPのVirtualization Stationにあるアカウント管理を
実際に試してみました

QNAP NASのOSであるQTS上のアカウントとは別に管理されていて
Virtualization Stationのみで機能するアカウント管理になります

アカウント登録

QTS上からVirtualization Stationの管理画面を開いて「アカウント管理」へ移動

右上にある「ユーザの作成」を選択すると入力フォームが出てきます
項目は文字通りの項目ばかりで超シンプルです

「VMのコントロール」部分がグレーアウトしているのは
コントロール権限が割り当てられていないからで
権限を付与すれば選択可能になります

仮想マシン権限については別項で紹介します

ユーザ登録完了するとリストに表示されます
コントロール権限を付与した状態だとこんな感じ
権限編集やパスワード変更はユーザ名のリンクを選択
ユーザ削除はチェックボックスで選択して「ユーザの削除」を選択

ログイン画面

QTS ログイン画面のURLはポートなしでもリダイレクトされるのでポート指定は不要ですが
http://NASIP:8080/
http://NASIP:8081/

Virtualization Station ログイン画面のURLは
http://NASIP:8088/
https://NASIP:8089/

ポート番号が微妙に違います
ポート番号はVirtualization Stationの設定画面から変更可能です

アクセスするとこんな感じ

右上からログインできます

何も権限を渡していないユーザであれば何も表示はされません

仮想マシン権限

各ユーザへ付与できる各権限を紹介します

コンソール権限

コントロール

VMをコントロールする権限でこれがないとあらゆる操作ができません
これを有効にしないと「VMのコントロール」権限がグレーアウトになります

当然コントロールする為には表示できないと使えませんので表示権限は自動で付与されます

画像のようにコントロールのみ付与してVMのコントロールに付与しない場合は
管理者が起動したVMを操作のみ可能

ユーザ側の画面

概要では表示権限があるのでVM01のみ表示
権限のないVM02は表示されていないのがわかります

コンソール画面のメニュー
電源や設定の権限は付与していないのでメニューにも表示されてません

OS上の操作は制限ありませんが
VMの設定権限を付与しないとCD/DVD ROMをいじれないので
ゲストツールCDボタンもありません

コンソール画面にはスタートボタンが表示されますが
電源権限がないと起動できません

VMの操作だけさせたい場合はこの権限だけ渡せば問題なしですが
OSからシャットダウンしてしまうとユーザ側で起動できないので
管理者に起動を頼まないといけなくなる点に注意です

表示

文字通り表示だけ許されるモードです
VMは見えますがVM内のマウス・キーボードに関しては一切操作できません
画面は見えるので管理者の操作を見せたい場合や
モニタリング画面を共有したいだけというケースに使えます

ユーザ側の画面

概要のVMリストは先ほどのコントロールと同じなのでVM個別画面を紹介
メニューも情報・ログしかありません（こちらもコントロールと同様の表記）
VM情報の表示は可能ですので構成情報などは確認可能

コンソール画面のメニューは操作が許されていないので
Ctrl+Alt+Delやファンクションキーのメニューが消されてます

表示権限のみではマウス操作もできないので
コントロールと違ってOS上でシャットダウンされる心配も不要です

VMのコントロール

電源

VMの電源操作に関する権限です

ユーザの画面

概要のVMリストでのサブメニューでも電源ボタンがでてきました

VM個別メニューでも同様

コンソール画面（VM起動前）

コンソール画面（VM起動中）

コントロール権限を付与するときはこの電源権限も付与しないと
OSフリーズ時やOS内からシャットダウンしてしまった際に
強制終了や起動ができず管理者へ連絡がくることになります

スナップショット

スナップショット操作を許可する権限です

ユーザの画面

概要のVMリストにスナップショットボタンが追加されます

VM個別画面も同様
メニューも情報・スナップショット・ログになっています

スナップショット管理画面はQTS上のVMスナップショット操作と同様です

スナップショットに関しては全権限が付与されていて
スナップショットの追加・削除も可能なので運用時はその点だけ注意です
（操作ログで誰が操作したかはわかります）

設定

VM設定の全メニューが利用できるようになります

ユーザの画面

概要のVMリスト
全ての権限を付与した状態になります
設定権限を付与すると設定ボタンだけでなくCD/DVDボタンも追加されます

VM個別画面でもアイコン追加され、メニューにも設定が追加されています
CD/DVD ROMに「ゲストツールCDを挿入する」ボタンも追加されます

コンソール画面のメニューでもVM設定があります

VM設定項目も同じです

CD/DVD ROMが追加されたのでマウントアイコンも表示されます

ところがISOマウントしようとしたところなぜか共有フォルダが見えませんでした
QTS上のVirtualization Station画面では表示されるので制限されているのか原因は不明です

ユーザの操作ログ

ユーザ側の画面でもVM個別画面にあるログ画面でVMごとの操作ログが記録を確認可能
こちらは管理者画面と違ってログ消去のボタンはなし

この画像では電源権限がないのに電源オンを試したログと
VMのキーボード設定をUSからJPへ変更した記録です

QTS上のVirtualization Station画面でのログ表示はこちら
全VMの操作が時系列で表示されており
VM操作以外にもユーザのログイン・ログアウト時間も確認可能
そして右上に「すべて消去」ボタンがあります

「すべて消去」ボタンでログをクリアすると
全てのログがクリアされるため管理者画面だけでなく
ユーザ側の画面でもログがクリアされます

その他

権限変更した場合いつ反映するか

設定適用ボタンを押した時点でほぼリアルタイムで反映されていて画面リロードも不要
ユーザ側では表示されている画面内で急にボタンが増えたり減ったりします

複数ユーザが同じVMのコンソール画面を開くとどうなるか

ブラウザ上のコンソール画面は排他制御されず同時にVMへ接続可能
マウス・キーボード操作も同時に可能ですが当然ながらマウスカーソルが飛ぶことになります

最後に

権限自体は大枠でしか設定できず細かい権限設定ができないのが難点ですが
ログイン画面にあるようにスマホやタブレットでも操作可能なので便利です

このサービスに限りませんがmyQNAPcloudで外部へNASを公開している場合は
パスワード設定には十分注意してください

最初に

QNAP TS-873-4G
メモリを64GB化済

Amazon | QNAP(キューナップ) TS-873 クアッドコア2.1 GHz CPU 4GBメモリ 8ベイ DTCP-IP/DLNA対応
https://amzn.to/34uq7oC

この記事ではVirtualization StationのVM設定で
ストレージ -> キャッシュモードの選択肢である
「None」「Writeback」「Writethrough」「Force Writeback」
4種類のモードを実際に試してみました

各キャッシュモードについて

QNAPサイト上での説明

[ライトバック] はNASページキャッシュを使用しています。NASキャッシュの容量がいっぱいになると、ディスクにすべてのキャッシュデータがライトバックされます。[ライトスルー] と比べると、[ライトバック] は転送速度に優れています。ただし、[ライトスルー] のほうが安全です。書き込みキャッシュを使用してディスクに直接データを書き込み、予想外のイベントが発生した場合にデータの損失を回避します。[なし] を選択すると、NASキャッシュが回避され、転送率の性能は [ライトバック] と [ライトスルー] の中間になります。

この解説が作られたときは「Force Writeback」が登場する前だったので触れられてませんが
速度は「Writeback」＞「None」＞「Writethrough」
安全性は「Writethrough」＞「None」≒「Writeback」という感じです

「Writeback」と「Writethrough」についてはRAIDカードでもよく使うので
RAIDカード方面で調べると資料がいろいろあると思います

「Writeback」はメモリ上でしか書き込みデータがない状態で電源が落ちると
VMイメージファイルの破損に繋がる恐れがあるのでUPS環境推奨になります

実際にVMで検証

HDD（ST1000DM010）2台でRAID1構成
ストレージプール作成し非暗号化シックボリューム内に配置
HDDインターフェイスはVirtIO

アイドル状態におけるCPU使用率について

画像内でアイドル状態におけるCPU使用率が10%前後になっている現象について
先に触れておきます

WindowsVMを起動 -> CDM起動 -> 放置して処理が落ち着くのを待つ ->
落ち着いたらCDM計測開始 -> シャットダウン
という流れで検証を行いました

その中でCDMを起動すると計測してなくても起動しているだけで
何故かNAS側のCPU使用率が上がり
CDMを終了するとNAS側のCPU使用率も落ち着くといった現象が発生
VMのWindows上ではタスクマネージャーでもCPU使用率は上がっておらず理由は不明

前記事ではCDM起動してすぐ計測していたので気付いていませんでした

None

CrystalDiskMark v7.0.0fの結果（前記事と同じ画像です）

CPU使用率とメモリ使用率

VM起動前

CDM計測直前

CDM計測後（IO待機が上がっている部分が計測中）

VMシャットダウン後

まとめ

計測中でもメモリ使用率・キャッシュ容量に変動がないので
NAS側としてはキャッシュなどメモリを使用せず
直で読み書きしているのがわかります

使用しているHDD・SSDやRAID構成に速度が素直に左右されるせいか
NASローカル計測記事のように計測毎で結果が結構バラつきがある点に注意が必要
（シーケンシャルで50MB/s程度の誤差あり）

VM割り当てメモリ容量以外はメモリを消費しないので
搭載メモリが少ないNASでもSMBサービスなどに影響しにくく
VMシャットダウン後も綺麗にリソースが戻るので
Noneで満足な速度が出る環境であればこれがベストと思います

Writeback

CrystalDiskMark v7.0.0fの結果

CPU使用率とメモリ使用率

最初の2画像が直前の別VM分も映っていて紛らわしくてすいません

VM起動前

CDM計測直前（左のIO待機の山は関係ありません）

CDM計測後
計測開始ポイントは左のシステムグラフが上がっているところ
メモリ使用率もキャッシュグラフが上がっています

VMシャットダウン後

まとめ

Noneと違ってVM起動前からCDM計測直前までの間（OS起動の読み書き）だけで
キャッシュ値が400MBから2.6GBまで増加します

CDM計測設定が1GB計測なのでCDM計測後に更に1GBのキャッシュ増加も確認できます
もちろんキャッシュ枠なのでVMシャットダウン後もすぐには解放はされません

VM割り当て分+キャッシュ領域が必要でメモリ消費量は多く
キャッシュ領域が不足していれば逆効果になる場合もありますが
メモリをフル活用する分、データがヒットすればかなりスピードは向上します

当然ながら仕組み上、メモリにないデータには効果はありません

CDM計測中でも実際のIOまでにラグがあるので結果的にIO待機のピーク値が低く済んでいて
NAS側のメモリ量に余裕があって遅いHDDをブーストしたい時には選択肢になるでしょう

ただ停電時などにデータ損失・VM丸ごと破損のリスクが高いので
UPSやバックアップしながらの運用が必要になります

Writethrough

CrystalDiskMark v7.0.0fの結果

CPU使用率とメモリ使用率

VM起動前

CDM計測直前

CDM計測後

VMシャットダウン後

まとめ

書き込みをすぐ確実に処理する仕組み上、書き込み速度はかなり遅いですが
Noneと違ってキャッシュ領域は使用するので書き込んだデータもキャッシュに残ります
なのでCDMのようにテストデータを作ってすぐ利用するような用途ではかなり有効です

CDM計測後の画像を見てもIO待機を見ればCDMの動きがよくわかり
最初のIO待機が読み込みテスト用のテストデータ生成
後ろの4つ連続するIO待機が各書き込み計測中になります

NAS側のメモリ量に余裕があって読み込みデータが多いWEBサーバなどのVM向け

Force Writeback

キャッシュモードを変更しようとするとForce Writebackのみ警告が表示されます

CrystalDiskMark v7.0.0fの結果

CPU使用率とメモリ使用率

VM起動前

CDM計測直前

CDM計測後

VMシャットダウン後

まとめ

Force Writebackは2019年1月に追加されたばかりの機能ということもあり
資料がなく安定性やリスクについての情報が見当たらず判断が難しいですが
パフォーマンス最優先というだけあってWritebackより高速なので
せっかくリスクを許容するならWritebackよりこっちでもいい気がします

最後に

CrystalDiskMarkではかなり高速化してますが
全てのデータが高速化するわけではなく
これらはあくまでキャッシュデータだけが高速化する話ですので
それ以外のデータは全てストレージプールの構成内容によって上限速度が決まります

速度を求めるVMであれば根本をSSD化することをまず考えましょう

QNAP機の場合はSMBはもちろんのこと、いろんなアプリでメモリを使うでしょうから
キャッシュ領域が不足すると他のアプリに影響するのでその点もお忘れなく

キャッシュ領域はNAS再起動はもちろんQboostでいつでも解放できます

VM用途によって効果は全然違いますしこの設定はすぐに変更できますので
まずはお試しあれ