機能 #867
完了ネットワーク構成再考 (2025-11)
nop_thread さんが2ヶ月前に追加. 約1ヶ月前に更新.
100%
NO nop_thread さんが2ヶ月前に更新 操作 #1
- 関連している braindump #568: Ceph の運用を考える を追加
NO nop_thread さんが2ヶ月前に更新 操作 #2
braindump #568: Ceph の運用を考える を考えていて、やはり Ceph 用とそれ以外用 (主にシステム管理用とサービス用) のネットワークは分離する必要がある気がしてきている (特に NVMe SSD を使うなら)。
そうなるとサービス用の線は冗長化できなくなりそうで、それはそれで本当に良いのだろうかという気持ちになってくる。
現状だと LACP で冗長化しているので1本ずつ抜きながら作業したりできるが、はたしてその必要があるのかと言われるとたぶんない。
どちらかというと Mikrotik のスイッチや YAMAHA のルータのファームウェアをアップグレードするときに接続が止まる方が実用上は問題。
それにネットワークカードの故障を考えるにしても、サーバ側で同じカードから2口 SFP+ が生えている NIC を使っているので、故障耐性としてもたぶんそんなに大した嬉しさはない。
現状でもし冗長化を考えるなら、 Mikrotik の同じスイッチがせっかく2台あることを利用した構成とかだろうか。
しかしラックも2つあるからそれぞれ ToR スイッチにしたい気持ちが強く、わざわざ隣のラックからケーブルを引っ張ってきて物理配線を滅茶苦茶にしてまでスイッチの冗長化をしたいかというと現状ではそれも微妙。
NO nop_thread さんが2ヶ月前に更新 · 編集済み 操作 #3
現状:
- Mikrotik のスイッチ2台の容量にはそれぞれ余裕がある
- SFP+ で 10G×24 と QSFP+ で 40G×2 があり、しかもノンブロッキング
- mgmt VLAN 用のスイッチは安物で代用できるようアンマネージドの RJ45 1G×24 を使っている
- これは1台しかないので、ラック毎に設置するとしてもう1台あっても良いといえば良い、が、確実に余る (VLAN もないのに 24U ラックで24ポートを管理用に使いきれるわけがない)
- ルータの冗長化はない
- RTX1300 なので、冗長性のために手軽に出せるお値段ではない…… (どうせ一番可用性が低いのはコンセントの電源そのものだし……)
- サーバ側では基本的に M/B 上の RJ45 端子を mgmt VLAN 用に利用し、 PCIe で増設した SFP+×2 NIC 1枚を LACP で束ねて tag VLAN で使っている。
- つまりケーブルは冗長化されているが、ネットワーク機器やサーバ内部は冗長化されていない。
- これは NAS (kanade) でも同じ。
- toka は PCIe スロットに余裕があるので NIC の冗長化もできるが、あれを動かす予定は当面ない。少なくとも今の家では。 (cf. #426#note-21)
NO nop_thread さんが約1ヶ月前に更新 操作 #4
- 前回確認日 を 2025/11/09 から 2025/11/30 に変更
どう弄るにせよ、手始めにポートを空けておくのが良さそう。
LACP にしてあるのを外してみるか。
NO nop_thread さんが約1ヶ月前に更新 操作 #5
nop_thread さんは #note-4 で書きました:
どう弄るにせよ、手始めにポートを空けておくのが良さそう。
LACP にしてあるのを外してみるか。
ケーブルを抜くならついでにケーブルにタグ (物理) も付けたい。
これを機に NetBox でのケーブル管理をちゃんとやるべきかもしれない。
NO nop_thread さんが約1ヶ月前に更新 · 編集済み 操作 #6
- 前回確認日 を 2025/11/30 から 2025/12/06 に変更
現状のポート利用:
- nagisa, sakuno
- RJ45 1G ×1 (for mgmt)
- RJ45 2.5G ×1 (unused)
- SFP+ 10G ×2 (LACP)
- millicent
- RJ45 1G ×1 (for mgmt)
- SFP+ 10G ×2 (LACP)
- yonagi
- RJ45 1G ×4 (1 for mgmt, 3 unused)
- SFP+ 10G ×2 (LACP)
- kanade
- RJ45 1G ×1 (IPMI)
- RJ45 10G ×2 (1 for mgmt, 1 unused)
- SFP+ 10G ×2 (LACP)
所感:
nagisa, sakuno の RJ45 2.5G は持て余している。
ないよりはマシかもしれないが、 10G でもないので発熱の激しい SFP+ の 10GBASE-T モジュールを使うほどのものではないし、 2.5G ネイティブ対応の asumi はポートが足りていない状況だがもう1台スイッチを引っ張り出してくるほどのことでもない。
1GbE として使う手はもちろんあるが、ここで millicent が足を引っぱる。
millicent は M/B 側で RJ45 ポートを1つしか提供していないため、 nagisa や sakuno のようにポートを余らせていない。
どうせスイッチが足りていない状況ではあるものの、もし millicent が余分なポートを持っていれば、 chuable のノード間でデータを転送するために mgmt とは別のネットワークを用意できたかもしれない。
kanade は仕方ないので RJ45 10G のポートを片方 mgmt 用にしているが、明らかにオーバースペックで勿体ないので、何か考えたいところではある。
かといって USB to RJ45 (1G) とかで信頼性があるかというと怪しいところ (たとえばデバイス名の永続化と設定の安定した適用などがうまくいくか不明)。
PCIe で増設している NIC の都合で SFP+ はすべて2ポートずつになっているが、現状では LACP で束ねている。
束ねたところで今のところ 10GbE で足りていないわけではなさそうなので、 NAS では片方を空けて別用途のために予約しておくのは悪くないが、今のところ使い道は他に思い付かないので一旦束ねたまま放置して良いかもしれない。
chuable のノードは片方をサービス提供用にしてもう片方を Ceph 用にするなどの使い道がありそう (#568) なので、さっさと束ねるのをやめてみて良いかも。
chuable のノードは USB がほぼ丸々空いているので、 USB to SFP とか USB to SFP+ とか USB to RJ45 のアダプタでポートを増設する手がある。
安定性や Linux 対応については多少の心配があるものの、スイッチ側ポートに余裕があるなら悪くないアイデアかもしれない。
(ただし USB to SFP などは怪しい製品ばかりだし、 USB to SFP+ は割と高価だったりするので、軽率に1つ用意して試してみようと思える状況ではない。覚悟が要る。)
NO nop_thread さんが約1ヶ月前に更新 操作 #7
- ステータス を 新規 から 進行中 に変更
- 前回確認日 を 2025/12/06 から 2025/12/07 に変更
VLAN を再編成。
- mgmt (1): デバイスの管理画面、クラスタの設定同期など、クリティカルなものを突っ込む。トラフィックが詰まるなんてもってのほか。スイッチが死んで VLAN の使えない状況になってもどうにか接続できる程度にはシンプルにしておきたいので、 untagged かつ /24 でやっていく。
- backbone (301): NAS を突っ込んだりクラスタ間の VM 転送に使ったりなどする。インフラ基盤側のデバイスやサービス間でデカいデータをやりとりするための場所。 gadgets VLAN の PC から NAS に接続するときなどにもここを使うかもしれない。たぶん。旧 lab VLAN に相当。
- intsvc (306): インフラ基盤ではないようなサービス全般を突っ込む。仮想化されたゲストとかで動いているものも大半はここに突っ込むことになるはず。こちらは詰まっても QoL が下がるだけで致命傷にはならない。本当は PC から NAS に繋ぐときはこちらを使う方が良いかもしれないが、それは NAS の設定が面倒かどうか次第なのでひとまず判断を保留しておく。
- chuable-ceph (305): chuable の Ceph の同期用。いざとなったらスイッチを物理的に隔離できるよう、VLAN を分けて備えておく。
- public (302): 外部からの接続を受け付ける。DMZ と呼ぶこともあるかもしれない。
- gadgets (303): PC、スマホ、ゲーム機、 IoT デバイスなどなど「程々に信頼していて、同じ LAN に集まっていると嬉しい」くらいのものを突っ込む。PC が gadget かというと怪しいのでいい感じの名前を何か考えたいものだが。
- guest (304): ゲスト……は基本的に来ないが、信頼できないあるいは同じ LAN にいる必要のない IoT デバイスなどを突っ込む。 mgmt VLAN 等の重要な場所にはアクセスさせない。
Proxmox VE の SDN 機能から VNet のために使っている VLAN とそのためのブリッジインターフェースは、何故かクラスタの migration network や Ceph のネットワークの選択画面に出てこない。
ソースを追った感じでは VNet に CIDR が割り当てられていないのが原因ではないかとぼんやり予想している (確信はない) が、そもそも VNet における CIDR もとい subnet の扱いなども全然わからないので、諦めて VNet 用の VLAN (intsvc) とホスト等の VLAN (backbone) を分離することにした。
こうすると migration や replication 等は backbone でやって普通のサービスのトラフィックは intsvc で流すという分別もできるので、結果的にはうまいこと整理できた気がするし悪くない。
NO nop_thread さんが約1ヶ月前に更新 操作 #8
- ステータス を 進行中 から 終了 に変更
- 開始日 を 2025/12/06 にセット
- 進捗率 を 0 から 100 に変更
- 管理外残件あり を いいえ にセット
Ceph 用のネットワークを分離できた。
といってもケーブルとポートこそ違えど物理的には同じスイッチに集まるが……。
まあノンブロッキングスイッチなのでべつにええやろということで。
故障したらその時は予備をデプロイすればよろしい (めんどくせ)。