MinIO on TopoLVM
そこそこの信頼性のオブジェクトストレージが欲しい
それぞれのノードに HDD を複数繋ぎ，それぞれのディスクに分散して保存し……といった理解でいい
要件
0. オブジェクトストレージ実装から見えるディスクはローカルディスクであってほしい
負荷的には別に分散ブロックストレージ + シングルディスク構成でもいいのだが，下に書くような問題を本質的には解いていない
1. それぞれのディスクの一部を切り出してオブジェクトストレージ用にしたい
高信頼性ブロックストレージが欲しくなるかも
プールは構成が固定なので，ノード追加などした場合には新しくプールを作り直す必要が出てくる
プールの数だけ新しいディスクを買ったり設置したりする余裕は金銭的にも物理的にもない
2. 同じノードに存在する，同じプールに所属する Pod は別のディスクから切り出したボリュームを使ってほしい
領域が余っているからといって同じディスクから切り出していたらノード単位の冗長化が全然だめということになってしまう
方針
とりあえずこれでいいんじゃないでしょうか
検討
2.の解決で困っている
展開の効率化のために MinIO Operator を使おうと考えているが，volumeClaimTemplate は1つしか設定できない
内部的には StatefulSet と Pod Topology Spread Constraints を使っているはずなので当然ではあるが…… TopoLVM は1つの StorageClass が lvmd における 1つの device class(VG) に紐付いているので，ノード内でのストレージの配置を元に割り当てを工夫するみたいなことは難しい 少なくとも Dynamic Provisioning はできないということになる
では PV を別に作ってしまえば……ということになるかもしれないが，TopoLVM は Pod のスケジューリングと密接に結びついているので別ノードの PV を Pod が掴もうとしてうまくいかずに壊れるみたいになってしまうはず 案としては
1. MinIO Operator ではなく自力でデプロイする
storageClass が異なる複数の StatefulSet としてデプロイし，MinIO のコンフィグ側で辻褄を合わせる
設定が煩雑
operator はサポートしてないけど minio は1つで複数のストレージを扱えるらしいです
解散解散
同様の問題は Rook/Ceph の PVC-based setup でも起こるはず TopoLVM を分散ストレージ基盤のためのローカルストレージ基盤として考えたときの問題として一般化できる 複数の device class にまたがった StorageClass が欲しいという話であり，協力を得やすいのでは
The dedicated feature: It would be better to create a different controller than adding this feature to TopoLVM because this feature conflicts with the topolvm concepts a lot.
そ，そんな……