# マルチベンダーLosslessネットワーク ## 定義 RDMA/RoCEv2 の Lossless(無損失)通信を、異なるベンダー(および ASIC)のスイッチが混在する環境で実現すること。PFC(Priority Flow Control)と ECN/DCQCN を用いた輻輳制御は ASIC 実装依存のパラメータ(キューサイズ・バッファ配分・輻輳閾値・フローレット識別時間)を持ち、単一ベンダー環境では最適化が容易だが、混在環境では各スイッチの挙動が干渉して輻輳制御が破綻しやすい。 ## 横断的知見 - **AR(Adaptive Routing)と DLB(Dynamic Load Balancing)の単純 on/off では不十分(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: NVIDIA SN4700(Mellanox ASIC)と Juniper QFX5240(Broadcom ASIC)の混在環境では、Spine の AR + Leaf の DLB を組み合わせても CNP(Congestion Notification Packet)とパケットのリオーダーが発生した。AR + DLB on が最悪で、DLB off が最もリオーダー未発生だが性能は低い。 - **Ingress interface hashing + DLB の組み合わせが実用解(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: Spine(SN4700)でトラフィックが入ってきたインターフェースに応じて ECMP ハッシュを計算する "Ingress interface hashing" を有効にし、Leaf(QFX5240)で DLB を使うことで、Reorder 発生が DLB 単体比で低下し CNP 発生率が大幅に低下。デフォルト設定比でスループットがほぼ 2 倍に改善。 - **DLB の inactivity-interval に最適値は存在しない(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: フローレットを識別するための inactivity-interval は長すぎると負荷分散効果が弱まり、短すぎるとリオーダーが増加する。nccl-tests では "常に最良" の値が存在せず、本番環境では総合的に良い結果が出る値を経験的に選択している。将来的な自動最適化機能への期待が述べられている。 - **DCQCN パラメータは ASIC ごとに調整が必要(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: OS/ASIC が変わるとキュー・バッファの扱いが異なり、PFC/ECN の伝搬挙動が変化する。単一 ASIC 環境で最適化されたパラメータをそのまま流用できない。 ## 未解決の問い - DLB の inactivity-interval の自動最適化は可能か? スイッチベンダーの将来実装を待つ以外にユーザー側で最適化する手法はあるか? - Ingress interface hashing + DLB の組み合わせよりも優れた手法が存在するか? - マルチベンダー構成での DCQCN パラメータチューニングのベストプラクティスを体系化する手法は? - 1.6T スイッチや CPO スイッチ時代にこの問題はどう変化するか? ## 関連 - [[データセンター輻輳制御]] — PFC/ECN/DCQCN の基礎 - [[RoCE設計課題]] — RoCE の構造的課題の体系化 - [[RDMA]] — Lossless 通信の前提 - [[Rail-Optimizedトポロジ]] — マルチベンダー構成で使うネットワークトポロジ - [[Juniper QFX5240]] — Broadcom ASIC スイッチ側 - [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]] — 実運用事例 ## 出典 - [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]