自宅のTV録画サーバ兼NASを新調した。
録画サーバとNASを前に作ったのは 8 年前で、ほぼ8年間稼働しっぱなしだったので、さすがに古くなってきたと思って新調した。
今年始めにメインのデスクトップPCを組んだので、今年に入ってから2台目の自作PCとなった。まぁ、そういうこともある。
ハードウェア構成
ハードウェア構成はこんな感じ。ケースとケースファンは流用。
| 項目 | 型番とか | 大体の値段 |
|---|---|---|
| マザーボード | ASRock H610M-HDV/M.2 | \11000 くらい |
| CPU | intel Celeron G6900(Alder Lake) | \7000 くらい |
| メモリ | ADATA AX4U320088G16A-DCBK20 8GBの2枚セット | \7300 くらい |
| システム用 m.2 SSD | Western Digital WDS480G2G0C 480GB | \6300 くらい |
| 電源 | Scythe CORE-TFX275 | \3300 くらい |
| データ保存用 HDD | Seagate ST8000DM004 8TB | \15000 くらいを2台 |
| 合計 | \65000 くらい |
データ保存用のHDD を除くと \35000 くらいで、既製品の NAS の箱と同じくらいの値段になったりするのだけど、メモリを16GB積めていてこれがキャッシュとしてきいてくれていい感じであってくれ、という気持ち。
でも家のネットワークが未だに 1GBit Ethernet なので結局こっちがネックになる感じはある。
CPU はAlder Lake世代で一番性能が低いものだけど、用途を考えれば十分だと思う。というか、シングル性能は i9-10900 と変わらないということらしくなんか未だに CPU は進化を続けているのだなぁと思う。
いろいろなことをしたくなって性能に不足を感じるようになってきても、多分 i3 くらいまでは載せ替えても電源の面でも熱の面でも問題は起きないと思う。
録画機能の選定
8年前は、chinachu というTV録画用のwebサービスを使って、環境を構築した。
今回も chinachu を使おうと考えていたのだけど、この8年の間に chinachu のテレビ録画ボードを操作するAPIを提供することを目的とした部分が Mirakurun として切り出され、 chinachu 自体にはこの API を操作するための Web UI が残されるという機能分割が行われたようだった。
で、その Web UI の方についても obsolete になるらしく、じゃあどうやって使えばいいのかと思ったんだけど、 Web UI の部分を置き換えるいくつかの代替品があるらしく、それと組み合わせて使うといった形になったらしい。
今回は、Web UI としては EPGStation というものを使うことにした。
EPGStation と chinachu はともに Docker 内で動くようになっており、両方をまとめて起動できる docker-compose 用のファイルも配布されていたので、これを使うことにした。
心残り
標準の状態では Quick Sync Video を使わずに、完全にソフトウェアでトランスコードするので、トランスコード時の CPU の負荷が高い。
Dockerfile 内で FFMpeg をコンパイルしているので、ここで必要なライブラリやコンパイルオプションの追加をすれば、 QSV を利用可能になる。でも、とりあえずソフトウェアエンコーディングでも性能が足りているようなので、後回しにすると決めた。
OS の選定
録画機能がDocker コンテナの中で動くということで、物理マシンに直接インストールする OS についての制限はなさそうだったので、長期的にちゃんとアップデートを行っていくことを念頭に置き、 arch linux をホストの OS として用いることにした。
NAS 機能
録画機能が docker-compose で管理されているので、NAS機能の方も docker-compose で管理することにした。
debian のベースに samba をインストールした Dockerfile を書いて、それを使った。
NAS 用のディスクは btrfs の RAID 1 でフォーマットした。1台壊れても大丈夫だし、容量足りなくなったら大きめのディスクを足せば良いだけのはず。
心残り
samba に対する書き込みを行っている際に、 docker-proxy というプロセスがそこそこ CPU を使っていることに気づいた。
このプロセスはコンテナの中と外の通信を仲介する役割であり、–userland-proxy=false オプションを docker daemon に与えるとこれを使わずに、iptables で代替の処理を処理を行うようになるようだ。多分、iptables でやったほうが軽くなるだろうとは思うのだけど、とりあえず性能面で今すぐ困る感じにはならなかったので、標準の状態でいいやと言うことにした。
今後、コンテナで大量の通信を行うような利用法を考えるときにはこのオプションについて真面目に検討しようと思う。