機能 #133
未完了Proxmox Backup Server を検討
30%
説明
- Introduction — Proxmox Backup 3.1.2-1 documentation
- Installation — Proxmox Backup 3.1.2-1 documentation
Periodic backups produce large amounts of duplicate data. The deduplication layer avoids redundancy and minimizes the storage space used.
ストレージ自体には今のところ余裕があるものの (といっても既に toka で PVE 用の dataset は 1.55 TiB を占めている)、基本的に Debian ベースでコンテナを立てることが極めて多く、またこれから Docker の利用も考えていることを考慮すると、重複排除機能は嬉しい。
Recommended Server System Requirements¶
- CPU: Modern AMD or Intel 64-bit based CPU, with at least 4 cores
- Memory: minimum 4 GiB for the OS, filesystem cache and Proxmox Backup Server daemons. Add at least another GiB per TiB storage space.
- OS storage:
- 32 GiB, or more, free storage space
- Use a hardware RAID with battery protected write cache (BBU) or a redundant ZFS setup (ZFS is not compatible with a hardware RAID controller).
- Backup storage:
- Use only SSDs, for best results
- If HDDs are used: Using a metadata cache is highly recommended, for example, add a ZFS special device mirror.
- Redundant Multi-GBit/s network interface cards (NICs)
特にメモリの要件を考えると、検証はさておきプロダクション環境を yonagi 上に VM で立てるのは厳しそう。
もちろん Proxmox VE 上に VM で立てても仕方ないので (クラスタが壊滅したときにこそバックアップが必要になるため)、ミニ PC を専用で調達して使うのが良いように思われる。
toka 上に VM を立てる手もないではないが、あまり TrueNAS の VM でいろいろやりたくないという気持ちがある。
(特に Plugins ではなくカスタムで立てた VM だと、 toka が壊れて kanade にメインを切り替えるとなったとき手間取りそうで……)
nop_thread さんが10ヶ月前に更新
NFS をストレージとして使うことを考えていたが、どうもプライマリなバックアップの保存先はローカルな ZFS が前提になっている?
もう少し調べてみる。
nop_thread さんが10ヶ月前に更新
ミニ PC の方にも考えるべきことはあって、電源ユニットがだいたい外にあるのが嫌。どうせ大したサイズではないのだから本体に仕込まれていてほしいのだが……
Mini-ITX の M/B を探して自前で組むという手も考えられるが、メモリとストレージを大きく積みづらそうなのであまり向いているとも思えない。
nop_thread さんが10ヶ月前に更新
今のところ toka のストレージが 22 TB (増強予定あり) なので、メモリは 26 GB 以上あることが望ましいということになる。
32 GB か 64 GB ということになろう。やはり物理マシンを1台占有させるべきだ。
どうせ計算力にはあまりこだわらない (メモリが積めればひとまずは良い) から、いっそラック増設 (#123) を前提に支持レールで載せられるサイズの安い BTO マシンを用意するのはありかもしれない。
高さ 37〜44.5 cm くらいのデスクトップ PC なら、たぶん探せば結構あるはず。
nop_thread さんが10ヶ月前に更新
PBS 自体にもレプリケーション機能があるので、もしそちらを使うなら toka 側のレプリケーション機能と重複しないようにセットアップする必要はありそう。
NAS に全てのレプリケーションを委ねるのと各種実装が固有に持つレプリケーションの活用、どちらが良いかは難しいが。
前者はバックアップ先の管理やディザスタリカバリが楽になるが、今のところ NAS そのものの冗長運用はしていないため、 SPoF としての NAS の重要度を高めてしまい、重大事故の際の被害が大きくなる (たとえばデータ喪失までいかずともダウンタイム増加などの) リスクが残る。
後者は実装固有の最適化や機能を活用しやすいが、同種の実装をバックアップ先にも立てる必要があり計算資源のオーバーヘッドは無視できない。
nop_thread さんが10ヶ月前に更新
NFS は使えるようだが、 PBS 側にネイティブなサポートがあるわけではなく普通にマウントして使うことになるらしい。
権限まわりの落とし穴は嫌だな。
nop_thread さんが10ヶ月前に更新
Firstly: while it works to add NFS shares to PBS, it is not built for that.
To add a NFS to PBS and use it as a Datasore, you need to adjust your permission in the nfs share [1][2][3][4] since by default a mounted nfs file will havenobody
as user and group, which won't allow you to use a directory as datastore on that nfs.
nop_thread さんが10ヶ月前に更新
PVE で VM を作ってそれを TrueNAS 側にコピーして設定をちょっと修正してやると、 TrueNAS 側への VM 導入が簡単になるらしい。なんだそれ……
nop_thread さんが10ヶ月前に更新 · 編集済み
PBS 同士で replication できることを利用して、 PVE 上の PBS と別ホストの (yonagi 上とかの) PBS で同期するという手もある。
容量は倍〜3倍 (PBS1 on toka, PBS2 on yonagi, toka's backup on yonagi) 消費するが、相当な dedup が効くはずなので 33% 以下への圧縮なら割と勝算がありそう。
本格的に依存するかは別途検討するとして、とりあえずその構成のつもりで PVE 上と yonagi 上に PBS を立ててみるのが良さそう。
nop_thread さんが10ヶ月前に更新
- 関連している 機能 #69: TrueNAS 以外の NAS (yonagi, maruri, ashe) の運用を再考する を追加
nop_thread さんが10ヶ月前に更新
しかしセカンダリな PBS を VM に立てるのはやはり良くないか。
ZFS on ZFS でないにせよ、 ZFS on btrfs もおそらく on ZFS と同様の理由で推奨されないだろうし、であれば yonagi 上に立てても地雷を埋めることになるだけかもしれない。
実験用途ではありだろうが……やはり使い物になりそうであればミニ PC なり何なりで専用マシンを立てるほかないか。
しかしミニ PC ではストレージをどうするかという問題もある。 JBOD エンクロージャでも用意するか?
nop_thread さんが10ヶ月前に更新
SilverStone の SST-RM41-H08 (4U ラックマウントの PC ケース) に惹かれている。
ただ、やはり PBS 単体にストレージをしっかり積むかはよく考える必要がある。
nop_thread さんが10ヶ月前に更新
そもそも巨大なデータは NFS とか iSCSI とかで NAS を直接使う形になるだろうから、 chuable だけで見ればバックアップすべきシステムは基本的に 1TB の NVMe SSD に収まる程度 (あるいはせいぜいそのノード数倍) になる。
つまり 8TB の HDD を2つ積んでミラーするだけでも VM/CT バックアップとしてはかなり長く使える気がする。
問題は、 PBS をサーバ類以外のバックアップに使おうとするとどうなるかということ。
世代管理したくなるようなバックアップがサーバ外にいかほどあるかは不明だが、デスクトップ PC 等のバックアップをこれでやりたくなる可能性は割とあると思っている。
(クライアントの対応プラットフォームはどうだっけ……)
nop_thread さんが7ヶ月前に更新
But be aware, that GC tasks will need an eternity to finish in case your TrueNAS is only using HDDs without a SSD for L2ARC or special device.
--- Running pbs as vm inside truenas ? Your advice | Proxmox Support Forum (comment 2)
弊宅の NAS のストレージは基本的に HDD で運用されているため、 NFS 経由にせよ VM にせよこのまま PBS を動かそうとすると碌なことにならない気がしてきている。
やはり適当な専用マシンを調達してくるべきか。
nop_thread さんが7ヶ月前に更新 · 編集済み
試算:
- CPU + M/B : 37k (tsukumo, セット)
- メモリ (16G×2枚組) : 10k (tsukumo)
- 4Uラックマウントケース+レール : 33k (amazon, amazon)
- CPUファン : 13k (tsukumo)
- PSU (850W, Platinum) : 23k (tsukumo)
- dGPU : 14k (amazon)
- ケースファン (80mm ×2 NF-A8 PWM) (optional) : 2.4k×2 = 5k (tsukumo, 売切))
- SSD 500 GB (システム用) : 8k (tsukumo)
- SATA SSD も NVMe M.2 SSD も 500 GB だと価格はだいたい同じ。
- 10G NIC : 13k (amazon)
- SFP+ DAC ケーブル (1.5m ×2) : 4k (amazon)
- SSD (データストア用)
- SSD 4TB ×2 : 40k ×2 = 80k (tsukumo) または
- SSD 8TB : 80k (tsukumo)
総額: ¥235k (ストレージ抜きで 155k)
ありといえばありか。
ラックに空きがないのが一番の問題だが。
nop_thread さんが7ヶ月前に更新
ミニ PC を見てみたが、ただでさえ諸々の品質が心配なのに加えて、安いものはストレージの積み増しができなそうだし、ちょっとスペックがマシなものを選ぼうとすると ¥80k〜140k くらいは普通にいくので、であれば最初からラックマウント前提で自作するのでよさそう。
nop_thread さんが7ヶ月前に更新
2TB 帯だと NVMe M.2 SSD の方が SATA SSD よりも若干安い。
どうせストレージを SSD にするのであれば、 SATA ポートが多いよりも M.2 スロットが多いことを優先する方が良いのかもしれない。
考え直し。
nop_thread さんが7ヶ月前に更新
Zen5 が今年中に発売されるだろうとの噂があるため、それでもう1台組んで nagisa (#206, CPU が Ryzen 7 3800X) と交換することも考えた。
しかしサーバについては現状まあまあ余力があるため御祝儀価格で買うほど性能が欲しいわけでもなく、また為替の不安定さや SSD の生産や価格への不安を考えると、今のうちに安く調達できそうなものはしておいた方が良い。
(もちろん CPU と M/B 以外のものだけ揃えておくのでも良いが、半年寝かせるのも保証期間などの面からあまり望ましくないし、なによりバックアップソリューションをはやく稼動させたい。)
3800X と 5700X の性能にそこまで差はないようだが電力効率は 5700X の方が良いので、 chuable に組み込むならこちらの方がマシと思われ、今から買うことも正当化できるといえばできるだろう。
nop_thread さんが7ヶ月前に更新
nop_thread さんは #note-23 で書きました:
2TB 帯だと NVMe M.2 SSD の方が SATA SSD よりも若干安い。
どうせストレージを SSD にするのであれば、 SATA ポートが多いよりも M.2 スロットが多いことを優先する方が良いのかもしれない。
考え直し。
近年の M/B であれば M.2 スロットは最低でも2つはあるから、とりあえずそれらを使って NVMe SSD のストライピングで 2 TB ×2 できれば当面はどうにかなるだろう。
もしデスクトップやラップトップのサイズが膨らんで厳しかった場合は SATA SSD で 2TB ×4 などして、余った NVMe はデスクトップなり chuable のクラスタなりに積めば良い。
nop_thread さんが6ヶ月前に更新 · 編集済み
toka に PBS の VM をテストで立ててみているが、バックアップが 6 MB/s くらいからその 1/100 くらいまで揺れまくっている。
実機でここまで論外なスペックにはならないはずなので VM 固有の問題なのだろうが、それにしても評価が難しい。
1.35 GiB の LXC CT の初回バックアップで10時間16分かかっていたりするなど、速度については全く参考にならない。
サイズについては、7コンテナ64バックアップ (うち3つは同じ構成なので実質5コンテナと考えて良い) で 5 GiB いかないくらい。1コンテナあたり 0.5 GiB 以上で 1 GiB 前後といったところなので、 incremental backup によるサイズ削減は相応に効いていると考えて良い。
ただ、コンテナを跨いだ dedupについては効果はみられるものの過剰に期待しない方が良いかもしれない。
nop_thread さんが6ヶ月前に更新
- 前回確認日 を 2024/05/26 にセット
37コンテナの計736スナップショットで GC した直後が 30.63 GB、 deduplication factor 55.64。なかなか悪くない。
とにかく時間がかかるのが問題だが、これはおそらく VM 固有の問題のはずなので、実機で動かせば大丈夫だろう。
nop_thread さんが6ヶ月前に更新
- ステータス を 進行中 から 待機中 に変更
- 確認予定日 を 2024/06/30 にセット
次に実機でサーバを追加するとしたら 2024-06 に発表されるとの噂の Ryzen 9000 系で Proxmox VE ノードを追加して代わりに nagisa の Ryzen 7 3800X をバックアップ機に使うという形になりそう (これでもまだバックアップ専用サーバには性能が高すぎるくらいだが……)。
とりあえず Ryzen 9000 のスペックや状況を確認するまでは待機。
nop_thread さんが6ヶ月前に更新
Ryzen 9000シリーズは,Zen 5を初めて採用するCPUで開発コードネーム「Granite Ridge」として知られていたCPUだ。現行のRyzen 7000シリーズの後継となるSocket AM5プラットフォーム向けの製品で,2024年7月以降に出荷を開始する。
—AMD,新世代CPUアーキテクチャ「Zen 5」採用の新型CPU「Ryzen 9000」と「Ryzen AI 300」を発表
……らしいので、9950X の価格と性能、その時点での 7950X の価格などを比較して考えることになりそう。
nop_thread さんが4ヶ月前に更新
- 前回確認日 を 2024/06/07 から 2024/07/20 に変更
nop_thread さんは #note-26 で書きました:
toka に PBS の VM をテストで立ててみているが、バックアップが 6 MB/s くらいからその 1/100 くらいまで揺れまくっている。
実機でここまで論外なスペックにはならないはずなので VM 固有の問題なのだろうが、それにしても評価が難しい。
1.35 GiB の LXC CT の初回バックアップで10時間16分かかっていたりするなど、速度については全く参考にならない。
chuable (PVE) 上に qemu VM で立ててバックエンドのストレージを NVMe M.2 SSD にしてみたところ、秒数を数えるのも馬鹿らしいほど爆速で初回バックアップが終わった。
どうやら VM だからという問題ではなく HDD が全面的に悪そう。
というのも、 write の瞬間最大が 2.85k IOPS だったので、これは SSD であれば SATA でも余裕で捌けるが、 7200rpm で 80 IOPS 程度の HDD ではそれはそれはつらかったはずである。
逆に toka に立てていたものはよく使い物になったものだ (なってないか)。
https://mastodon.cardina1.red/@lo48576/112429893043052519 によれば write が 6.5 IOPS だったようだから、ざっと400倍程度の性能が出たことになる。
このくらい速いと NVMe である意味はまったくなく、ネイティブにせよ VM にせよ SATA で十分だろう。
そのうち chuable にも 2 TB の SATA SSD でも載せるべきだろうか。
でも SATA SSD は筐体内での固定できる場所に限りがあるし、 NVMe M.2 スロットも空いているから、価格差がない今の状況で敢えて SATA にしたいかというと微妙。悩ましい。
参考までに read は 434 IOPS 程度だったが、初回バックアップなのでこの値はほぼ無意味のはず。
nop_thread さんが4ヶ月前に更新 · 編集済み
初回バックアップ、35スナップショットの時点で deduplication factor は 4.28、ストレージの usage は 15.72 GB だった。
だいたいどのコンテナもプラットフォームは LXC の Debian なのでもう少し効いても良さそうには思えるが、増分スナップショットなしでこの数値は十分に満足できる。
nop_thread さんが4ヶ月前に更新 · 編集済み
- ステータス を 待機中 から 進行中 に変更
- 進捗率 を 0 から 30 に変更
- 前回確認日 を 2024/07/20 から 2024/07/31 に変更
今のところ問題なく動いている。
メモリを与えれば与えるだけ食うのでどうなっているのかと思ったら、ほぼ全てが buff/cache へと飲み込まれている。
$ free -m
total used free shared buff/cache available
Mem: 5928 502 212 0 5504 5425
Swap: 3915 0 3915
$
メモリは食いまくるが、 CPU は何を使っても基本的に余りそう。
(VM 仮想4コアで瞬間的に 80% 食っている時間帯はあったが、 weekly view で3時間単位の目盛だと平均 1.14% という数値になってしまうので、本当にごく短期間のスパイクである。
これをベアメタルで動かしたいかというと、正直かなり怪しい。
chuable とは独立した Proxmox VE ノードを立てて、他のストレージ要求が重くて落ちても致命的でないサービスとかを相乗りさせてやる方が良いのではないかという気がしている。
べつに chuable に参加させて駄目ということもないのだが、バックアップという目的を考えると独立して動く方が望ましいのと、ストレージ要求が重いとどうせクラスタ内での replication がつらくなり migration もそんなにうまくいかない可能性が高いので、結局は分離したくなるのではないかと思う。
nop_thread さんが4ヶ月前に更新 · 編集済み
nop_thread さんは #note-39 で書きました:
メモリを与えれば与えるだけ食うのでどうなっているのかと思ったら、ほぼ全てが buff/cache へと飲み込まれている。
Verify All を実行したら急激に buff/cache が高まり限界に達した。それはそう。
verify 完了後、PBS 内のダッシュボードからは「10.76% (421.73 MiB of 3.83 GiB)」と報告されており、べつに困ることはなさそう。
気にする必要はない。
nop_thread さんが3ヶ月前に更新
- 確認予定日 を削除 (
2024/08/31) - 前回確認日 を 2024/07/31 から 2024/09/01 に変更
- 管理外残件あり を いいえ にセット
何らかの形で PBS を動かしたいというのはもう揺るがないが、では具体的にどこで運用するのかという話は 機能 #457: ストレージを食いまくるサービス用に、独立した Proxmox VE クラスタを用意するべきか検討 のアイデアが浮上してきたため一旦保留。
nop_thread さんが3ヶ月前に更新
- 次のチケットがブロック 機能 #457: ストレージを食いまくるサービス用に、独立した Proxmox VE クラスタを用意するべきか検討 を追加