(一般人には)高いQNAPのNASを個人宅で運用した感想

2023年2月頃に TS-h886 というQNAPのNASを購入していました。

というわけで、まいにゅーぎあ。。。 pic.twitter.com/i5NTBaqEtw
— ingen084 (@ingen084) February 14, 2023

経緯

我が家では2019年3月頃から自作PCで ZFS を使用した NAS を運用していました。環境としてはこんな感じです。

OS: Debian 9
CPU: i7-4790
MEM: 32GB
SSD(システム): 1TB
SSD(キャッシュ) : 120GB * 2
HDD(メインプール(RAIDZ2)): 4TB * 6

なんとなく安定して使えていたのですが、いくつか問題がありました。

CPUの世代が古く、性能に対しての消費電力が高い(現行と比較して9世代前だそうで…)
Debian の ZFS for Linux では iSCSI が利用できない(Ubuntu にすれば解決はする)
メモリが 32GB しか搭載できず、 ARC を使用しているとほかに使用できるメモリ容量が少ない
HDDのケースがない

最後についてはかなり致命的で、SATA拡張ボードで拡張した6台のHDDを無理やりケースから出して運用していました。
ホコリがたまりやすかったりHDDの交換がめちゃくちゃ大変だったりと大変苦労しており、裸族のスカイタワーを購入し USB 接続にしようとしたりなども試みたのですが、どうもチップかドライバの相性が悪いらしく USB3.0 で接続するとデバイスが不定期に切断される問題が発生したりと散々でした。

さすがにシリコンケースでは熱が籠りすぎるので最終的に裸族のビキニ+ファンを無理やり結束バンドでくっつける運用になりました。

2022年の年末、容量が不足してきたのもあり HDD を 8TB に交換したときに大変だったのと、サーバーの台数が多く消費電力が増えており、サーバーを統合し省エネにすることも考え始めたのが購入のきっかけでした。

機種の選定

基本的に NAS というのは RAID などの機能を持ったネットワーク経由でファイルを共有するための機器ですが、ここ最近の NAS は基本的にストレージがいっぱい挿せる Linux であるため様々な機能を持たせることが可能で、VM や Docker / LXD コンテナを動かすことができたりします。

そのうえでサーバーを購入するつもりで選ぼうとしていたのですが、 QNAP に ZFS ベースの圧縮や重複排除機能が利用可能な QuTS hero (という OS)があることを知り、これを使ってみたいと思いました。

すでに6台の HDD を持っていたので、6台以上の HDD を搭載できる機種を選ぶことにしました。

当時の比較表

適当に高すぎないものをピックアップしてみたつもりですが、やはり高いですね…。
この中で ZFS に対応しておりサーバーとしても使えそうなのは　TS-h886 だったのでこれを購入することにしました。
検討機種が少なすぎる説はありますが、まあいいでしょう。

購入

という経緯があり、27万円で QNAP の TS-h886 を購入しました。
購入時に楽天のアカウントが止められたりとか、1週間後にAmazonで6万安く出品されてたりとかいろいろあったのですがそこらへんは割愛しておきます…。つらい。

セットアップ

QNAP の NAS は利用を始める前に追加アプリなどをインストールするためにメインとなるストレージプールの作成が必要になります。
TS-h886 には、 M.2 SSD が 2つ 2.5インチ SSD が 2つ 3.5インチ SSD が6つ搭載できるのですが、いろいろ悩んだ結果、

システムプール: M.2 SSD * 2 (RAID1)
メインプール: 3.5インチ HDD * 6 (RAIDZ2)
- キャッシュ: 2.5インチ SSD * 2

とすることにしました。 M.2 SSD を丸々キャッシュにして 2.5インチ SSD をシステムプールにする作戦もありましたが、システムプール上でコンテナアプリを動かしたかったのと、SSD の寿命が溶けるキャッシュは交換しやすいようにしておきたかったのでこういう構成になりました。

すべて1つにまとめては？と思ったかもしれませんが、これは QNAP のドキュメントに、

システムの性能と安定性のためには、システムプールはSSDのみで構成すべきです。

とあったので分離することになりました。

移行

同じ ZFS なので単に HDD を差し替えて zfs import すればよいという説もありましたが、ZFSのバージョンの違いからうまくいかない、といった情報や重複排除を効かせるようにするために rsync コマンドでファイルを転送することにしました。

すでに稼働中の NAS は 8TB のHDDを搭載しており、手元には 4TB の HDD しかありませんでしたが、換装したばかりであり十分 4TB のプール内に収まる範囲だったため次のように移行を行いました。

旧環境で snapshot を作成する
新環境へ rsync でスナップショットの内容を送信する
旧環境のサービスを止め、スナップショット時点から現在までの差分を送信する
旧環境に新環境をマウントし、サービスを再開する
新環境の 4TB の HDD を1台ずつ 8TB に交換する

で、ダウンタイムを短くした状態で移行を行いました。

移行時間としては、ファイルの転送に4日、HDDの交換に1週間程度かかりました。
HDDの交換途中、再同期(resilver) が非常に遅くなることがありましたが、これはNASの再起動で解決しました(その際サービスがダウンしたのはいうまでもなく…)。

使い心地

これがこの記事の本題です。引っ張ってすみません。

性能

正直あまり変わりません。ZFS が割といい感じにやってくれるのでキャッシュも効くし、書き込みが集中すると詰まるのも変わっておらず、HDD の限界を感じました。
ですが、リソースは効率よく使えている…かもしれません。dedup を有効にした時の性能の低下は感じなくなっていて、そこはよかったかもしれません。
とはいえ自作PCでもチューニングすればなんとかなりそうな気もしています。その料金を支払ったと思ってよいのではないかなと思います。(随分高いけど)

機能

GUI で設定できる以外は ZFS for Linux と変わりないように見えます。
SMB とか NFS で共有したりする機能も変わりありません。

めちゃくちゃ便利に感じたのは、自動でスナップショットを取って、それを定期的に削除してくれる機能です。
スマートバージョン管理という物が存在し、毎時スナップショットを取り、1日経過するとその日の最後の1件だけ保持、1か月経過するとその月の最後の1件だけ保持、みたいな感じで短期間では高頻度、長期間では低頻度でスナップショットを残してくれます。
役に立つ日は来ないでほしいですが、素の ZFS だと zfsnap とか入れて細かい設定をする必要があるので、雑にやってほしい自分にとっては便利でした。

ちなみに差分がないとスナップショットは取られません。

Web管理ツール

Web経由で情報が見られるのはとてもいいですね！とくにスナップショットのタイムラインとかが見られるのは便利です。
が、メディアライブラリとか使わないんですよね。いろいろ表示できるのはいいけど、CUI になれているとあまり使わないかもしれません。

あとは…ネットワークの設定とか VM の操作とかもWeb上からできるのは便利だったかもしれません。

ssh

管理ツールから有効にすることで利用可能です。
Linux カーネルではありますが、いろいろなディレクトリ構造などが異なっているため、普通のサーバーとはちょっと異なります。

どこまでかは僕もよくわかってないですが、かなりのディレクトリが再起動時にリセットされるらしく、基本的にデータはホームディレクトリに置くことになるのかなと思います。ホームディレクトリはシステムプールにマウントされており、そのほかにストレージプールの共有フォルダは /share/ 以下にマウントされていました。

コンテナ･VMサーバーとして

Container Station というアプリをインストールすることで docker/docker-compose/lxc コマンドが利用可能になります。
ちょっと癖があるため、自宅サーバーとしては少し使いづらいかもしれません。顧客の社内とか実家に置いてくるぐらいのレベルならいいかもしれませんが…。

まずバージョンが古いです。

[ingen084@TS-H886 ~]$ docker version
Client:
 Version:           20.10.17-qnap10
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        0474f29
 Built:             Wed Apr 26 10:52:38 2023
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.17-qnap10
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       ee3ebf2
  Built:            Wed Apr 26 10:45:20 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc:
  Version:          1.1.2
  GitCommit:        v1.1.2-0-ga916309f
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
[ingen084@TS-H886 ~]$ docker-compose version
docker-compose version 1.29.2, build 1ca12643
docker-py version: 5.0.0
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019
[ingen084@TS-H886 ~]$ lxc version
Client version: 4.14
Server version: 4.14

docker は結構成熟しているのもあったり、サーバー間連携で問題が発生することは少ないですが、LXC がかなり問題でバージョンが違うとメタデータが変わってくるため、コンテナを移動させるときに問題が発生します。
また CRIU がインストールされていないためライブマイグレーションもできません。
今後の記事で書く予定ですが、VMを建ててその中で動かすのがよいと思います。ちなみに、QEMU が LXD が参照できる位置にインストールされていないので LXC の VM モードは使用できません。

一応各種コマンドはほぼフルで使用できるので、NAS 単体でコンテナを動かすだけであればあまり問題はないかと思います。

仮想マシン

Virtualization Station というアプリをインストールすることで仮想マシンを作成できます。
ライブマイグレーションなどにも対応しているのですが、結構独自形式っぽく、利用するにはほかの QNAP の NAS と連携する必要がありそうです。
がんばって LXD の設定を変えればなんとかなるのかな、よくわからん…。

詰まったポイントなど

vim

vim が初期から入っているのですが、 vi 互換モードになっており僕みたいな素人には非常につらかったです。
ホームディレクトリに .vimrc を作成しておくといい感じになりました。これでいいのかはわかりません。

set backspace=indent,eol,start
set nocompatible

コンテナのGPU共有

NVIDIA のグラボを挿すことでコンテナとGPUを共有することができるのですが、コマンドからコンテナを起動した場合共有させることができません。
詳細はあまり把握できてないのですが、GUI から共有設定をつけて起動することで共有できるようになりました。

PCIe デバイスのVMへのマウント

PT3 を使用して録画サーバーを立ち上げているのですが、QNAP の NAS での PCIe デバイスのマウントは検索したら結構出てきますが、新しい情報がなさそうだったのでここに書き記しておきます。
lspci コマンドを追加で入れているサイトもありますが、最近のバージョンでは？最初から入っているのでIDで grep して設置場所を特定します。

[ingen084@TS-H886 ~]$ lspci | grep 1172
06:00.0 Class 0480: 1172:4c15

で、アタッチ用の XML を作成します。

<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
  </source>
</hostdev>

でこのページを参考にスクリプトを作成しておきます。

#!/bin/bash
DOMAIN=356de4c6-1ed6-427c-b4e9-7213a01239ec
/QVS/usr/bin/virsh attach-device $DOMAIN --file pci_device.xml --config
/QVS/usr/bin/virsh reboot $DOMAIN

再起動するたびにこのスクリプトを実行する必要があるのと、スクリプトでは reboot と書いていますが実際には一度VMを終了しないとアタッチされません。
この2点に気を付ける必要があります。

欠点

アプデ･起動時間

起動にめちゃくちゃ時間がかかります！15分ぐらいかかります。
ボリュームのサイズが大きくなればなるほど時間がかかるのでは…という気はするのですがまだわかりません。

そのうえで2～3か月に1度再起動必須のアップデートがあります。(安定版の QuTS hero を使用しています)
コンテナ上で動かしているサービスに対して2～3か月に一度サービス停止はまあ許容するにしても再起動見守ったりとかはとてもめんどくさいです。PT3 のアタッチをやり直さないといけないですし。
これは明確に自作PCのほうがよかったポイントです。ubuntu みたく livepatch できませんかね…。

あとは初期設定だと勝手に再起動するように設定されていたりするので気を付けましょう！

また、システムが立ち上がりきらないとコンテナ･VMが起動しません。場合によってはアプデだけで30分サービスが停止する可能性があり、少しつらいところがあります。

音

それなりにうるさいです！アイドル状態でラックマウントサーバー(DL360)のアイドル状態と同じかそれよりちょっと静かぐらいです。
僕はもうすでに慣れているので大したことないですが、一緒に寝るのはお勧めできないかもしれません。
あと温度が高くなると相応にうるさくなるので、夏の間にエアコンをつけずに耐久したい人にはお勧めしません。

ちなみにうちのラックマウントサーバーがフルパワーで動き始めると家全体が震えるそうです。怖いね。

物理的な性能

見ている人もうすうす勘付いていたと思いますが、CPU だけ見ると性能は微妙なんですよね。

10Gbps とかでファイル転送をするとそれだけで CPU 使用率が 90% ぐらいになったりします。
なのであくまでWebサーバーとか、負荷がかからない用途に使うのが一番なのかなあとは思っているのですが、実績として minio で2.5Gbps出したりなど、自宅Webサーバーとして利用する程度であれば十分な性能があるように感じます。
次回の記事あたりでゲームサーバーを動かしてみたりなど、負荷のかかることをして評価してみる予定です。

まとめ

細かいセットアップの手間を省いていろいろサクッと設定できるのはそれなりにいいかもしれません。
DIYユーザーとしては物足りない点もありますが、脳死でバージョンアップを適用しているだけでメンテが不要なのは楽だと思います。
とはいえ高価なのもあり圧倒的な優位性は感じませんでした。ケースとかに困っていなければ自作PCのほうがいいと思います。もちろん問題は自分で解決する前提になりますが。
アリエクで売ってる HDD いっぱい搭載できる怪しいケースのレビューしてる人いないかな。

動かしているサービスや LXD とかについての細かい話は次回の記事で書く予定です。

おまけ

知識を披露してくれる Copilot

財布のひもがぶっ壊れたので限界までメモリを拡張した

NASのメモリを限界まで増やしました() pic.twitter.com/COdyqt3DCR
— ingen084 (@ingen084) June 25, 2023

メモリ制限 64GB の VM とか建てそう(小並)