プロジェクト

全般

プロフィール

機能 #330

完了

minio サーバのセットアップ

nop_thread さんが17日前に追加. 1日前に更新.

ステータス:
終了
優先度:
通常
担当者:
開始日:
期日:
進捗率:

100%

予定工数:
一時中断:
いいえ
meta:
いいえ
pinned:
いいえ
確認予定日:
前回確認日:

説明

今のところ toka (TrueNAS) に雑に立てて誤魔化しているが、真面目に運用する前にどうするか考える必要がある。


関連するチケット 3 (2件未完了1件完了)

関連している 鯖缶 - 機能 #332: デスクトップとラップトップのバックアップ機構の検討新規

操作
関連している 鯖缶 - 機能 #333: ネットワーク構成再考 [2024-05]終了nop_thread

操作
次のチケットに先行 鯖缶 - 機能 #331: メトリクス監視のセットアップ新規nop_thread

操作

nop_thread さんが17日前に更新

Core Operational Concepts — MinIO Object Storage for Linux によれば、以下の3つのシステムトポロジーがサポートされている。

  • Single Node Single Drive
  • Single Node Multi Drive
  • Multi Node Multi Drive

ここでいう Drive とは物理ドライブに限らずフォルダのことも指している様子。

Deploy MinIO: Multi-Node Multi-Drive — MinIO Object Storage for Linux によると、 (フォルダのことを想定していないような記述なのが気になるがさておき、) "Changed in version RELEASE.2024-01-28T22-35-53Z: MinIO pre-allocates 2GiB of system memory at startup." とか "MinIO recommends a minimum of 32GiB of memory per host." とか、なかなか激しいことを書いてある。
"Use Consistent Size of Drive" とも言われているので、 Minio レベルで multi node 構成をする価値があるかは慎重に考える必要がある。
「落ちたら他で立ち上げる」ができるなら多少のダウンタイムは許容できる可能性がある。

nop_thread さんが17日前に更新 · 編集済み

問題は minio サーバとストレージバックエンドを別ホストにすると実質的に通信が倍増する点で、今のところ仮で立てている minio サーバを TrueNAS 上に置いているのはこれが理由。
Ceph のような分散ストレージで Proxmox 側でデータ共有をできるならそれもアリかもしれないが、そもそも Ceph で増加するリソース消費にそこまでする価値があるのか考える必要はある。
ストレージは増設すれば速くもデカくもできるのでまだ良いが、通信帯域の増強には限度がある。 10GbE で足りなくなったら次は25か40だぞ。

nop_thread さんが17日前に更新

  • 次のチケットに先行 機能 #331: メトリクス監視のセットアップ を追加

nop_thread さんが17日前に更新

  • 関連している 機能 #332: デスクトップとラップトップのバックアップ機構の検討 を追加

nop_thread さんが17日前に更新 · 編集済み

マルチノード構成とレプリケーションは別か。

All Sites Must use the Same MinIO Server Version

めんどい。

nop_thread さんが17日前に更新

もうこれを適当に回すのでいいか……

nop_thread さんが17日前に更新

あとはメインの minio サーバを TrueNAS 側に置くか Proxmox VE 側に置くか Synology DiskStation 側に置くか。
オーバーヘッドを最小にするという点では Proxmox VE をメインにするのはナシ寄り。
バックアップから復旧できる前提なら TrueNAS と DiskStation どちらを使っても問題ないが、 TrueNAS 側に置いておくと何かあったときの復旧は面倒な可能性があるが代わりにレプリケーションが効くので楽。
DiskStation 側に置いておくと Docker で立てることになるので別ホストでの復旧が楽かもしれないが、どうせ TrueNAS CORE で Docker を使えないからやっぱり復旧は面倒そう。

nop_thread さんが7日前に更新

  • 関連している 機能 #333: ネットワーク構成再考 [2024-05] を追加

nop_thread さんが6日前に更新

toka (TrueNAS CORE) に (jail で) 立てている MinIO でトラブルがあった。
toka の vlan インターフェースやデフォルトゲートウェイ等を変更したところ jail が追従してこず、 jail のネットワークの設定変更を試みてもエラーで失敗し、 jail を再起動しても問題が解決せず、 jail の vnet0 インターフェースに使われている bridge0 のメンバーをコマンドラインで変更しようとしても vlan301 が device busy だと言われてメンバの追加もできない。
仕方ないので諸々の設定を見直したうえで toka ごと再起動したら起動時の再設定がちゃんと行われたらしく回復した。

このことから、 TrueNAS CORE はやはりアプリを立てることに最適なわけではなく、ネットワークまわりとかで問題を抱えるとトラブルシューティングが面倒ということが身をもって実感できてしまった。
今はどうにかして Proxmox VE クラスタで効率良く minio を動かせないだろうかという方向性で考えている。

nop_thread さんが1日前に更新

PVE でやるとトラフィックの増幅も含めコンテナのセットアップや管理が面倒なので、やっぱり一発でセットアップと管理をできる toka か yonagi に任せたい。
暇してる yonagi が Linux (Docker) だし 10GbE×2 あるしで丁度良い気はするが。

しかし Synology DSM の container manager を調べていると、どうも bonded network に対して MACVLAN は使えないような話があり、そうであれば IP アドレスには多少不自由するかもしれない。

nop_thread さんが1日前に更新 · 編集済み

IP アドレスを選べないのは気掛かりなので、以下の戦略で行く。

  1. toka に (今立てているものとは別の) minio jail を立てて本格的に利用していく
  2. yonagi に Docker で minio container を立て、 mc mirror で継続的にミラーしていく
    • これはバックアップも兼ねている
  3. 容量を見守る
  4. 何かあったら容量と通信量次第でどうするか決める
    • toka に改めて立て直す
    • toka が完全に駄目そうなら replication 先の kanade で起動する
    • yonagi に切り替える
    • サイズが小さければ chuable に立てても良いかもしれない

nop_thread さんが1日前に更新

  • ステータス新規 から 終了 に変更
  • 担当者nop_thread にセット
  • 進捗率0 から 100 に変更

#note-11 の方針でやるということで toka に立てたので完了。

他の形式にエクスポート: Atom PDF