鯖缶

考え事と懸念:

toka のハードウェア¶

CPU をみるとどうにも Proxmox VE を載せるべきように思われるのだが I/O ポートの拡張性は PVE では持て余すので、そのミスマッチをどうするかというのが考えどころ。
PVE で36ベイは使い道がない。

toka の計算資源¶

toka の CPU (仮想40コア) は完全に持て余している。
一方でコア性能は高いとはいえず、 Ryzen 9 7950X にクロック周波数で2倍程度劣るうえ、キャッシュも L3 まで含めると 7950X の方が上。
TDP は Xeon がちょうど半分だが、結局2ソケットで使っているので Ryzen 9 7950X と同じくらいか。

つまり、 toka が計算資源の面で勝っている点は以下の点くらいで、それ以外は概ね Ryzen で良さそうである。

• ECC メモリ。
• 仮想コアが (32コアよりもさらに) 8コア多い。

拡張性と冗長性¶

以下の点は toka のハードウェアの強み。

• 安心の36ベイ。 HDD アレイと SSD アレイを同時に動かしても余裕
• x1 とかでなく x8 の真っ当な PCIe スロットが多数あるので、 NIC や HBA カードを積みまくれる
  • Gen3.0 x8 が6スロットある。この帯域なら実効 63.015 Gbps なので QSFP+ のポート (40Gbps) も生やせる
• PSU が2つあるので可用性を確保しやすい
  • ただし消費電力のオーバーヘッドはありそう
  • 可用性の確保を目的に考えると、 UPS の運用と toka の稼動のどちらが安いかは不明

ただし弱点もある。

• NVMe M.2 スロットがない
  • PCIe から変換するにしても Gen3.0 x8 なので Gen4.0 x4 に変換できるかはわからない (変換器次第だろう) し Gen5 の SSD にはおそらく不向き
• アイドル時でも十分な発熱
  • これ以上負荷をかけて良いものか……

Synology DSM と TrueNAS¶

• rsync で同期できるのはディレクトリツリーとファイルまでで、通常のファイルでないものの同期は事実上できないと考えてよい。
  • snapshot とか
  • TrueNAS の zvol とか
  • Synology DSM の iSCSI LUN とか
• rsync で同期するにしてもパーミッションまわりは本当に面倒。たぶんリストアはまともにできない
  • 同一プラットフォーム間レプリケーションだけで全てを済ますか、複雑なパーミッションやアクセス制御を使わないか、どちらか (あるいは両方) 選ぶしかない
• TrueNAS の plugins (minio とか) や VM は安定性が低く使い勝手も良くない
  • NIC まわりで hardware offloading を無効化しないと jail / VM 側でとんでもなくパフォーマンスが落ちるらしいとか (Very Slow Network Performance on Virtual Machines | TrueNAS Community)
    • なお無効化したらしたでホスト側でのパフォーマンスに悪影響があるらしいと警告が出る
  • ホスト側 (TrueNAS) で IP アドレスの変更などを行っても再起動なしに jail (plugin) にネットワーク設定を正しく反映できなかったりとか
  • VM が突然 CPU 使用率 100% に到達して ping も応答がなくなり VM を再起動することになったりとか

その他¶

• minio 等はリモートストレージを使って動かしたくないが、とはいえ NAS 並に可用性が重要なサービスになるはずなので、結局 NAS とストレージを直接共有するのが一番効率が良い
  • minio のストレージバックエンドをネットワーク越しにするとネットワーク帯域の浪費になるし速度も心配
  • minio を特定の仮想化ホストに紐付けてしまうと、 high availability は実現できなくなる
    • mc mirror によるバックアップ/ミラーリングからのリストアを前提にすることで HA 構成を諦める手もなくはないが。
• yonagi (Synology DSM) にキャッシュ用の NVMe ストレージを積んでいるので、折角なら活用したい気もする
  • TrueNAS でしっかりメモリを積めばその方が速くなるのではという気がしないでもないので、そこまで重視しているわけではない
• バックアップとリストアを Synology DSM でうまいことやれるようなら、 kanade をプライマリにして別の自作マシンを予備機 (フェイルオーバー用) の TrueNAS 機にする選択肢もあるかもしれない
  • 無理して toka を使う必要はないということ
  • kanade はメモリが 64 GB しかないのが残念だが、そこまで困るわけでもない。ただし ZFS キャッシュを大事にしたいので余計なアプリは動かす余裕がなくなる。

現状で toka を稼動させること自体が (健康面も含め) 大きすぎるコストなので、 toka は kanade の予備ハードウェアということにしておいて、そもそも日頃は起動しないような運用にしたい。
負荷をかけていない状態でも PSU からの熱風などなかなかのものなので、 Proxmox VE を動かすのも躊躇するレベル。

プライマリな NAS のバックアップハードウェアとして toka を持っておくのであれば、 replication によるバックアップ先は (一定の I/O 帯域が確保できさえすれば) 仮想マシン上の TrueNAS であっても構わないということになりそう。
その場合でも結局セカンダリな TrueNAS のストレージをどう持つかという問題はあるが。

PVE で Ceph を運用したいかという問題もあるが、なんにせよ NFS では問題があるものの可用性がそこまで重要とも限らないユースケース (典型的には #98#note-9 で考えているようなローカルの Docker レジストリ等) で何を使うか考えておかないといけない。
iSCSI でやろうということであれば TrueNAS は相性が悪いから Synology DSM をプライマリに動かしたいという話になるし、 Ceph ならストレージは PVE ノードに分散させようということになる。
意地でも全てを TrueNAS でやるのであれば、アプリの運用側に皺寄せがいくことは覚悟する必要がある。

逆に実は NAS の可用性がサーバアプリ群にとって重要でないということであれば、バックアップも気楽にできて zvol やら snapshot やらについて深く考える必要がなくなる可能性だってある。

プライマリな NAS の故障を考えるとき、計算機側の故障とストレージの故障とデータの破損を区別して考える必要がありそう。

• 計算機の故障
  • 予備機にストレージを載せ替えて TrueNAS で起動できれば良い。
• ストレージの故障
  • 冗長性の範囲内であればストレージ交換でいける
  • 確保した冗長性で耐えられなかった場合、ストレージを交換してアレイを組みなおしてバックアップ (あるいはレプリケーション先) からリストアしてくる必要がある。
• データの破損
  • ストレージはそのままにスナップショットかバックアップからのリストアができれば良い。

kanade をメインにして予備を toka でというのは計算機の故障への対策であって、バックアップやレプリケーションは依然としてどこかに確保する必要があるので、一番楽な方法を考えるのであればもう1台 TrueNAS 機を用意してそちらにレプリケーションすれば良いことになる。
だが、それならそのレプリケーション先を予備機としてしまえば良いわけで、 toka の存在意義はなくなる……？

Synology-to-Synology のレプリケーションが楽なのは活用していきたいところで、であれば自宅の yonagi から実家の maruri へ流すのが楽ということにはなる。
一方で yonagi はメモリと NVMe M.2 SSD の増設という性能面での強化があるため、バックアップ機としてだけ動かしておくのも微妙に勿体ない気がする。
HDD アレイであっても SSD キャッシュをもってすればそこそこの性能は期待して良いのではないかという気がするので……

気持ちとしては、ただでさえバックアップで嵩むストレージのコストが更に爆増しかねないため NAS に高可用性を求めたくなくはない。
となると、重要なアプリデータについては PVE の冗長構成に乗せてやるのが良くて Ceph をちゃんと勉強しなさいということになるのだが、その場合はストレージや構築コストではなくネットワークまわりが問題になってくる。
というのも、家庭用 M/B は PCIe スロットが少なすぎるゆえ 10GbE をそう簡単に追加で生やせないからである。

現状では SFP+ ×2 のカードを全ノードに増設しているため、これを LACP で使うのをやめてアプリ用に1ポートと Ceph 用に1ポートとする手はあるのだが、その場合接続不良や一時的なメンテナンスにおけるノード離脱の可能性が高まってしまう。
(むしろ HA 構成にしている以上はそういった状況に日頃から対処して慣れておくべきという考え方もできるかもしれないが……)

自前で NAS を組むのもハードウェア面がつらい。

• 筐体: それなりに選択肢はある
  • ラックマウントなら SilverStone とか
    • だいたい 4U か 5U でどうにかなる
  • タワー型なら Fractal Design の Define 7 とか
    • 最大 5"×1, 3.5"×14, 2.5"×4 というとんでもない収容力。ただし側面パネルを外してアクセスなどできないとホットスワップはつらそう
    • ただし横置きするなら高さ制限 (450 mm) がシビアでストレージ収容力も悩ましい。 Fractal Design だと Define R5 は収容力があるが高さ 451mm なのでスライドレールには乗せられず (台には乗る)、 Define C だと 440 mm なので問題ないが 3.5" ベイは2しかない
    • 横置きしないと10U とかのレベルで高さを食うので、だったらわざわざサーバラックに置かずともよくないか？ という話もある
• HBA: 相当つらい
  • 新品、それなりの安さ、信頼できそうなメーカー、という条件でそもそも入手可能そうなモノがない。
    • Amazon でクッッッッッソ胡散臭いブランドの格安 HBA はあったりするが、ストレージを冗長化しておきながらコントローラに信用できないものを使うのは本末転倒が過ぎる。 HBA が狂ったら接続先ストレージが全部駄目になるリスクもあるわけで。
    • Amazon で現実的な価格のものを探してみても、「ホットプラグ/ホットスワップ非対応」みたいなことが書いてあったりするので本当に油断ならない。
  • 参考までに、 Top Picks for FreeNAS HBAs (Host Bus Adapters) では SAS 3224, SAS 3216, SAS 3008, SAS 3016, SAS2308, SAS 2008 あたりがおすすめされている。
  • そもそも家庭向けの M/B では PCIe スロットが少なすぎて HBA と SFP+ の共存がギリギリ可能かどうかの瀬戸際といったレベルなので、そういう意味でも厳しい。困難なのは HBA の入手だけではない。
• M/B: つらい
  • AMD AM5 世代はもう SATA なんて4ポートかせいぜい6ポートが限度。
  • M.2 は4スロットあることもあるが、その場合 PCIe や SATA と排他になっていたり帯域を共有していたりするので、物理 I/F をフル活用できるとは限らない。
    • M.2 to SATA のボードを使う手はあるが、つまり貴重な M.2 スロットが減るということである。
  • HBA の項にも書いたが、 PCIe スロットも少なすぎるので最低限の拡張性の確保も難しい。 SFP+ ×2 で Gen3x8、HBA で Gen3x8、とやっているともう残りが x1 スロットとかしかない。

arco に使っている Define R5 のストレージ収容量が多い (3.5"/2.5" ×8、2.5" ×2) ため、別のケースを調達して arco をそちらに移動し、 Define R5 をラックに置くのでも良いかもしれない。

Fractal Design の Define シリーズを使うとどうなるかの検討。

縦置き¶

Define 7 Compact だと高さ 474 mm なので 11U (488.95 mm) 必要。
Define R5 も高さ 462 mm なので 11U で収まる。
これらのケースを縦置きする場合、汎用性を捨てて自宅にあるラックの特性だけを考えるなら横に2つ並べられるが、筐体あたり 6U ということになる。
デカすぎる。ちゃんとケースを選べば 4〜5U でレールを使えるのに。

横幅については、 100-SV00324U と専用棚板 (幅 54 cm 程度) であれば2台設置は可能。入口が 45 cm なのでそこはうまくやる必要があるが、出し入れだけ注意すれば設置自体は幅が計 45 cm を超えていても可能。
なお Define R5 の幅は 232 mm 、 Define 7 Compact の幅は 210 mm なので、少なくとも1つが Define 7 Compact であれば入口も含めて2台横並べが可能。
(とはいえ Define R5 と組み合わせて 442 mm だと間隔に余裕がなさすぎるので、結局はいずれにせよ入口付近を空けておいて奥に設置するということになるだろう。)

ちなみにスタンダードモデルの方の Define R7 は幅 240 mm なのでこちらも Compact との組み合わせなら許容範囲、高さも 475 mm なので 11U (488.95 mm) で Define R5 や Define 7 Compact に劣らない。
ただしストレージ収容量は 3.5"/2.5" ×6 (最大 ×14) と 2.5" ×2 (最大 ×4) なので、追加パーツを調達しない範囲においては Define R5 と大差がない。
そして 3.5" HDD を14台も用意できたとて、 M/B の SATA ポートが足りず信頼できる HBA の準備も難しいという問題が待ち受けている……

横置き¶

Define R5 の高さ 462 mm は19インチラックの横幅 (450 mm) を完全にオーバーしているため、寝かせたまま投入はできず、一旦立てた状態でラック内に持ち込んだのちその場で横倒しにする必要がある。
100-SV00324U と専用棚板であれば、入口をどうにか超えれば棚板に 54 cm 程度の横幅があるため設置できることは実際に試して確認済。

ただし Define R5 はフロントの扉 (これ自体はなんとか 434 mm なのでラックの入口に合わせられる) を開けるとケース側面よりも外側に出る (つまりラックの棚板か上の段を邪魔する) ため、扉を開けたままにするのは難しい。
また、 USB 端子の出る方向がケース上面 (つまりラック側面) になるため、これも使い辛い。
さらに、スライドレール等でないとケース内の HDD へのアクセスはかなり面倒になる。

占有する領域については、横幅 232 mm なので 6U (266.7 mm) 必要。 5U (222.25 mm) では 1 cm 足りない。

結論としては、 Define R5 であれば横置き設置は可能だが結局 6U 必要になるため、縦置きよりも特別に優れているということはない。

参考までに、 SilverStone の RM400 は 4U ラックマウントでレールも別売だが存在し、 5.25" ×3, 3.5" ×8, 2.5" ×(2+1) といった様子なので、 Fractal Design の Define R5 と同等で、しかも小さくラックマウント対応ということになる。
ホットスワップはかなり難しそう (クリアランス次第では不可能) だが、セカンダリな NAS として動かすならそこは気にならないし、そもそも安物の HBA などを使うなら無視できるかもしれない。
(ちなみにホットスワップしたいなら RM41-506 の 5.25 インチベイを追加部品 (FS305-12G) で 3.5インチベイ (ホットスワップ可) に切り替えられる。)
価格と CPU クーラーのサイズを無視すれば絶対にこちらの方が良い。

そして NAS 用途なら CPU はそこそこでよくメモリの方が大事なので、結局 CPU クーラーは大した問題ではなく価格だけの問題ということになる。

SilverStone の RM43-320-RS であればホットスワップ対応の 3.5" ベイが20あり、しかもバックプレーンが SFF-8643 ×5 と4ピンペリフェラル電源×5 になっている。
M/B 側の領域もしっかり 4U ぶんの高さが確保できる。

……と、ここまで書いて気付いたが、そもそも4ピンペリフェラル電源を5つも取り出せる電源ユニットがあまり多くないのだった。
(1つのバックプレーンで最大4台の HDD を駆動することを考えると、Y字ケーブルで同系統の電源から複数バックプレーンに給電するのは望ましくない。)
一応 SATA からペリフェラル電源にする変換器などはあるらしいが、どうせ品質の全く信頼できない格安製品しかないだろう。

結局、 NAS を自前でもう1台用意するのは主にハードウェア調達の問題のためあまりうまくやれると思えず、であればいざというとき toka を繋ぎとして稼動しその間に何か考えるということにしておいて、 TrueNAS をアクティブ-スタンバイ的に2台常時稼動させる方向性は捨てるべきかもしれない。
TrueNAS の replication に非依存の選択肢を探してみる。

nop_thread さんは #note-2 で書きました:

• rsync で同期できるのはディレクトリツリーとファイルまでで、通常のファイルでないものの同期は事実上できないと考えてよい。
  • snapshot とか

Creating Snapshots | TrueNAS Documentation Hub によれば、 TrueNAS の snapshot は普通に ZFS の snapshot なので隠しディレクトリ .zfs から普通に read only でアクセスできそう。
(ここでいう隠しディレクトリとは `ls -a とかでも出てこないようなものだったはず。私の記憶が正しければ。)

スナップショット名も periodic snapshot task の作成で指定できるから、スクリプトや rsync task によるバックアップは普通に可能だろう。
(もちろんアクセス権まわりはプラットフォームを跨いで持ち越すのが難しそうだしそれは問題だが、所詮個人での利用だからどうとでもなる。)

replication を使わず明示的に snapshot のディレクトリを指定してバックアップをするのであれば、 dataset はほどほどに少ないか安定しているべきなので、 NAS のデータ階層の整理も重要になってくる。

nop_thread さんは #note-21 で書きました:

早急に toka の運用を停止する必要がある。

2024-07-23 に運用を停止した (#175#note-30)。

ストレージ要求が重いサービスはレプリケーションなどしていられないので、 iSCSI とかで最初から NAS 側に確保したうえで全面的にそちらに依存して CPU とメモリだけ chuable のものを使う形にしたい。
とはいえプロトコルの選択に問題がある。

• iSCSI: ブロックデバイスが見えるのでパーミッションまわりは比較的素直に扱えるが、 PVE の iSCSI イニシエータは TrueNAS ターゲットに10秒ごととかのすごい勢いでエラーログを残していく爆撃をするので、本当に使いたくない
  • あとは SSD アレイでないと PBS のような用途は辛いかもしれない
• NFS: iSCSI のログの問題はないし、サイズも事前に気にする必要がないので楽だが、認証と権限まわりは面倒。
  • 認証は、そもそもできない (IP アドレスなんて LAN 内に悪意あるアクターがいればどうとでもなる)。
  • 権限は、クライアントが単一ユーザの owned:group しか使わない前提でサーバ側も mapall すれば、どうにか？
    • 任意の UNIX permission をそのまま保持するのは NAS 側のバックアップで支障が出そうなので避けたい。

nop_thread さんは #note-23 で書きました:

ストレージ要求が重いサービスはレプリケーションなどしていられないので、

重そうなもの:

• MinIO
  • 多用途。
  • Harbor (docker registry, cache proxy) は結構バカ食いしそう。最低 40 GB とか書いてあったし。
  • Thanos (メトリクス蓄積) も、今こそまだ小さく済んでいるがコンスタントに増えていくので、いずれ必ず PVE 内では replication したくない限界に到達する。
• Proxmox Backup Server
  • バックアップ用。
  • いずれはクラスタ内だけでなくデスクトップやラップトップ、 VPS にも使っていきたいと思っており、場合によっては TB 単位で必要。
• iSCSI target
  • もし本当に使うならの話だが、これもまとまった大きさのストレージ領域を要求するのでクラスタ外 (しかもおそらく TrueNAS の外) に立てることになる。
  • これは余力のある yonagi とかにネイティブでやらせるのが良い気がしている。 (バックアップをどうするかは要検討だが。)

nop_thread さんは #note-24 で書きました:

重そうなもの:

Subversion サーバも追加で。 (関連: #380)
現状で既に 300 GB 規模 (それ以上に膨らむことが想定される) のリポジトリとかを LAN 向けにホスティングしたいので、さすがに普通のノードに置きたくない。
本当は NAS に直接ホストできると良いのだが……