mastodon.cardina1.red は、数々の独立したMastodonサーバーのうちのひとつです。サーバーに登録してFediverseのコミュニティに加わってみませんか。

サーバーの情報

3
人のアクティブユーザー

Proxmox VE 触っててかなり嫌な気持ちになる挙動、 HA で自動マイグレーションかけるとき replication 対象でないノードに CT が移動して起動失敗するというのがある。

たとえば A, B, C で HA クラスタを組んでいて A 上の CT 100 で A→B の replication を設定している状態で A が落ちたとする。
ここで何故か CT 100 を C で起動しようとすることがあって、そうするともちろん C 上にはボリュームがないので起動失敗する。カス!

そこは replication のターゲットである B でやってほしいのだが、何故かそうならないんだよな。設定が悪いのかもわからんが、この程度のことに設定が必要な時点で仕様として駄目なのでやっぱり PVE が悪いと思う

らりお・ザ・何らかの🈗然㊌ソムリエ

で、何が面倒ってこの C に移動されたやつを A とか B に戻そうすると「ボリュームが missing だから移動できなかったわw」ちゅーて逆マイグレーションも失敗するので、仕方なく
mv /etc/pve/nodes/{C,A}/lxc/100.conf
みたいなことをやらないといけない。せめて web UI で戻せるようにならんかね……

こういうことがあるので replication が気休めにしかなっておらず、じゃあ A→B と A→C 両方設定すればいいじゃんというのはその通りなのだが、つまりストレージ使用量が純粋に3倍になるということなのでそれはそれで険しい。

で、どうせそうなるなら最初から Ceph とかでもっとちゃんとストレージ分散した方がええか? となるわけだけど、あれはあれでクラスタ全体のシャットダウンの下準備がダルいとか壊れたときが面倒とか通信帯域を余計に食われるのも嫌とか、まあいろいろ躊躇う理由がある

ちなみに NAS があるのに PVE の VM/CT 用に使わない理由は、 TrueNAS の iSCSI ターゲットと Proxmox VE クラスタの iSCSI イニシエータの相性が悪いためです (cf. <mastodon.cardina1.red/@lo48576>)

どうしてもという場合は VM/CT 内から SMB とか NFS でマウントかけることもあるけど、まあ最終手段やね

@lo48576

"つまりストレージ使用量が純粋に3倍になるということなので"

実はデータの可用性を考えると結局この考えに行きつかざるを得ないんだよね。 [参照]

@mmasuda NAS でどうにかしようとすれば stripe of mirrors 系の構成で2倍程度におさめられるしクラスタのノード数にも影響されないので、その点でもちょっとコスパ悪いよなぁと思ってしまいます (なおスイッチと NAS そのものの故障は心配しないものとする)