鯖缶

まずネットワークを飽和させないために専用のネットワークがあった方が良いらしい。
これは各サーバに SFP+ ×2 の NIC を積んでいるので問題ない。
現状だとサーバとスイッチ間を LACP で冗長化しているのはケーブルが抜けたり破損したときの備えでしかなく、帯域自体は 10Gbps で全然問題ない。

• 2.10. Red Hat Ceph Storage クラスターの電源をオフにして再起動 | Red Hat Product Documentation
• SES 7.1 | Deploying and Administering SUSE Enterprise Storage with Rook | Ceph cluster administration

微妙に OSD flags まわりの記述に差異があるが、とにかくシャットダウンに一手間かかりそうなのが面倒。

あと「クラスタを利用しているクライアントを全部止めろ」が最初に来ているのも地味に嫌かもしれない。
PVE 上のストレージを PVE 上のコンテナから使うのなら良いが、クラスタ外とかにクライアントを置くのは危険かもしれない。

• Clean shutdown of whole cluster | Proxmox Support Forum

どうにも挙動が怪しい？
詳しく読んでいないが、 2024-09 の話なのでかなり心配。

ドキュメントは 3839 – Documentation: Hyper-converged Ceph cluster shutdown and cold start によれば 2024-08-22 リリースの PVE 8.2.2 で更新されているが、実装についてはこれといって Ceph cluster のシャットダウン専用の何かは入っていない様子。

Deploy Hyper-Converged Ceph Cluster - Proxmox VE

理屈はわかったし納得もしたが、それはそれとして自動化されていないのは面倒。
「ceph のクライアントがいなくなった (典型的には VM/CT を全て停止した) ことを確認してから次の操作」とか、そもそも VM/CT, ceph, PVE node のシャットダウンが全部個別の操作になっているから3段階必要なところとか。

たぶん楽をするなら PVE API によるスクリプト操作を前提にやる必要があるのだろう。
ミスを減らす観点でもその方が良いので、覚悟を決めるべきかもしれない。

Ceph をやるか否かについては、既に圧倒的にやる側に傾いている。
ZFS の replication による HA がまともに動かないし、まともに動かないから手動での作業は必須と言っている人が他にもいるし、フォーラムで不満の声を上げている人へのレスポンスも滅茶苦茶だし。
replication は migration がちょっと高速になる程度の効果までしか期待してはいけないと思われる。

時間差でデータロスがどうとかそういう次元ではなく、そもそもフェイルオーバーすらうまく動かないのでお話にならない。
誰だこれで HA の代わりになるとか言ってるやつは。とんでもない。

2 TB の SSD を調達だけ済ませてあって未設置なのでまずは設置の必要があるが、 nagisa (#206) にはスロット不足で素直には設置できなそうな雰囲気がある (#224#note-9)。
NIC で x16、グラボで x1、PCIe to M.2 変換基板で x1、残りの x16 スロットはオンボードの M.2 用、という感じでかなりギリギリのやりくりをする必要がありそう。
とはいえ #224 の x1 スロットは (写真でしか確認していないが) デカい端子を挿せるタイプではなく x1 しか入らないよう端がきちんと閉じているタイプのように思われるので、スロットに刃を入れるかグラボを慎重に選ぶかなども考えないといけない。

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

nagisa (#206) にはスロット不足で素直には設置できなそうな雰囲気がある (#224#note-9)。

いっそ nagisa を抜きにして M.2 スロットが十分にある sakuno, millicent, 新規マシン の3台で Ceph クラスタを組むという手もあるにはあるはず。
それで PVE 側が4台体制になるのも微妙に気持ち悪い話ではあるが……。

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

2 TB の SSD を調達だけ済ませてあって未設置なのでまずは設置の必要があるが、 nagisa (#206) にはスロット不足で素直には設置できなそうな雰囲気がある (#224#note-9)。
NIC で x16、グラボで x1、PCIe to M.2 変換基板で x1、残りの x16 スロットはオンボードの M.2 用、という感じでかなりギリギリのやりくりをする必要がありそう。
とはいえ #224 の x1 スロットは (写真でしか確認していないが) デカい端子を挿せるタイプではなく x1 しか入らないよう端がきちんと閉じているタイプのように思われるので、スロットに刃を入れるかグラボを慎重に選ぶかなども考えないといけない。

以下のようにすればどうにかできる可能性がある。

• PCI_E1 (4.0x16): SFP+ ×2 NIC
• PCI_E2 (3.0x4, 端子は x16, M.2_2 利用時は両方とも 3.0x2):
  • NVMe M.2 スロットが計2つ (M.2_1, M.2_2) で良いなら不使用
  • もう1つ追加して計3つ欲しいなら、 PCIe to NVMe M.2 変換基板
• PCI_E3 (3.0x4, 端子は x16): M.2_2 と排他なので不使用
• PCI_E4 (3.0x1): グラボ
  • 3.0x1 帯域で十分で端子も x1 のものが……なんと既に持ってるんだなぁ、しかも 2.0x1: 設備・備品 #339: dGPU: ASUS, GeForce GT 730 (GT730-4H-SL-2GD5)

とはいえ NVMe M.2 スロットが2つで良いなら両方とも 3.0x4 帯域にできるが、3つ欲しくなったら M.2_2 と PCI_E2 を 3.0x2 にダウングレードすることになる。
PCIe 3.0x2 というと実効 15.754 Gbps = 1969 MB/s くらいなので、他の Ryzen 7000/9000 で動いているであろう Gen4x4 の 7300 MB/s 等とあまりにもパフォーマンスが離れてしまう。

Ceph だとノードあたりのディスクサイズとディスク数は揃えるべしとされているが、速度については HDD は遅すぎるから WAL / DB を SSD に乗せるといいぜ！ くらいしか言及がなく、 NVMe でも速度差が3〜4倍くらいある状況については何も言われていない。

Deploy Hyper-Converged Ceph Cluster:

Aside from the disk type, Ceph performs best with an evenly sized, and an evenly distributed amount of disks per node.

3〜4倍というと SATA 3.0 の SSD (帯域で最大 600 MB/s) と M.2 の PCIe 3.0x2 の NVMe SSD (帯域で最大 1969 MB/s) が3倍差なので、場合によっては device class から別物レベルとして扱うに値する程度の速度差に思われる。
本当にこれ (read がそれぞれ 7GB/s, 7GB/s, 2GB/s の組み合わせ) でプール組んで大丈夫なのか？

いや大丈夫には大丈夫なのかもしれないが、 2GB/s で律速されるのはあまりに勿体なくないか？
……と思ったが、どうせ internal network を 10 Gbps (+ public 10 Gbps) にしてしまっているので、心配せずともネットワークが先にボトルネックになるか。

とりあえず 3.0x4 なら約 4 GB/s くらい出るので、まあギリギリ許容範囲？