> [!abstract] 概要(Abstract の日本語訳) > RDMA(Remote Direct Memory Access)ネットワークにおいて、RNIC(RDMA NIC)を含むホスト内ネットワークは、これまで頑健だとみなされほとんど注目されてこなかった。しかし RNIC の線速が数百ギガビット規模へ急速に増加するにつれ、ホスト内ネットワークはネットワークアプリケーションにとって潜在的な性能ボトルネックになりつつある。ホスト内ネットワークのボトルネックは、ホスト内帯域の劣化とホスト内レイテンシの増加を引き起こしうる。加えて、RNIC ネットワークの問題は接続失敗やパケットドロップを引き起こしうる。ホストネットワークの問題はネットワーク性能を著しく損なう可能性がある。しかし、ホストネットワークの問題が発生しても、監視システムの欠如によりほとんど気づかれない。さらに、既存の診断機構はホストネットワークの問題を効率的に診断できない。本論文では、われわれの長期にわたるトラブルシューティング経験に基づきホストネットワーク問題の症状を分析し、ホストネットワークに特化した最初の監視・診断システムである Hostping を提案する。Hostping の核となるアイデアは、(1) ホスト内の RNIC とエンドポイントの間でループバックテストを実施してホスト内レイテンシと帯域を測定すること、および (2) ホスト上の RNIC 同士で相互プロービングを行うことである。われわれは分散機械学習システムの数千台のサーバに Hostping を展開した。Hostping は既に把握していたホストネットワーク問題を数分で検知・診断できるだけでなく、これまで気づいていなかった8件の問題も明らかにした。 ## 論文情報 - タイトル: Diagnosing End-Host Network Bottlenecks in RDMA Servers - 著者: Kefei Liu(BUPT・State Key Laboratory of Networking and Switching Technology)・Jiao Zhang(Senior Member, IEEE; BUPT および Purple Mountain Laboratories、責任著者)・Zhuo Jiang(Douyin Vision Company Ltd.)・Haoran Wei(BUPT および Douyin Vision Company Ltd.)・Xiaolong Zhong(BUPT)・Lizhuang Tan(Member, IEEE; Qilu University of Technology(Shandong Academy of Sciences)Shandong Provincial Key Laboratory of Computer Networks)・Tian Pan(Member, IEEE; BUPT)・Tao Huang(Senior Member, IEEE; BUPT) - 媒体: IEEE/ACM Transactions on Networking, Vol. 32, No. 5, October 2024, pp. 4302–4316(受理: 2024年6月9日、発行: 2024年7月16日)。DOI: 10.1109/TNET.2024.3416419 - 資金提供: Natural Science Foundation of Shandong Province(Grant ZR2023LZH011)、National Natural Science Foundation of China(Grant 62132022, 62372053)、Fok Ying Tung Education Foundation(Grant 171059) - コード・DOI: 論文中にコード公開の記載なし。 > [!note] [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]] との関係 > 本論文は同一著者グループによる Hostping システムの**拡張ジャーナル版**(IEEE/ACM Transactions on Networking, 2024)であり、NSDI '23 版(参考文献 [37] として本論文中に引用)を土台に (1) RNIC-to-RNIC(R2R)probing による RNIC ネットワーク問題(接続性・フラッピング・誤配線)の診断機構、(2) リンク状態推論の擬似コード(Algorithm 1)の定式化、(3) 新たに発見した2件の問題(#14 誤ったスイッチポート配線、#16 RNIC のビット誤り)、(4) RDMA verb 呼び出しエラーの検知やコンテナ実行など運用面の議論、を追加している。図表番号・実験環境(Figure 2 のホストトポロジ、Figure 1・3・4・7・8・9 の実測データ)は NSDI 版と共通のものが多く、本ページでは両版で共通する図表の解説を簡潔にとどめ、TNET 版で新規に追加された内容(R2R probing・RNIC ネットワーク問題・Algorithm 1・Experiences Learned の追加項目)を中心に記述する。 ## 概要 RNIC の線速が急速に向上する一方、PCIe をはじめとするホスト内帯域の伸びがそれに追いつかず、ホスト内ネットワークが RDMA 通信の新たなボトルネックになりつつあるという問題意識に加え、本論文は RNIC 自体の接続性問題(ルーティング誤設定・ハードウェア障害)もホストネットワーク問題の一種として扱う。著者らは (1) RNIC-エンドポイント間ループバックテストによるホスト内帯域・レイテンシの測定と、(2) 同一ホスト上の RNIC 同士による相互プロービング(R2R probing)という2つの核心アイデアを組み合わせた Hostping を提案する。数千台の本番分散機械学習サーバへの展開を通じて、CPU ルートポート障害・メモリチャネルフラッピング・RNIC の頻繁なビット誤りなど、これまで気づけなかった8種の新規問題を発見したと報告する。 ## 問題設定 - **入力**: RDMA サーバのホスト内トポロジ(RNIC・GPU・メモリノード・PCIe スイッチ・CPU ソケット間の物理接続)、RNIC の稼働状況(スループット、Tx pause frame 比率、パケットドロップ)、および同一ホスト上の他 RNIC への到達可能性。 - **出力**: (1) ホスト内の各リンク(RNIC PCIe リンク・GPU PCIe リンク・メモリチャネル・CPU ルートポート・UPI/QPI)の正常・異常判定と推定根本原因(リンク障害・トラフィック輻輳・設定ミス・フラッピング)、(2) 各 RNIC の接続性状態(正常・down・ルーティング誤設定・フラッピング)。 - **前提条件**: RDMA が有効な commodity RNIC(`ibv_reg_mr` / `ibv_post_send` 等の verbs API が使えること)。ホストは複数の RNIC を持ち、それらが同一 ToR(top-of-rack)スイッチに接続される Clos トポロジを想定する。ホストが busy/idle を行き来するデータセンター運用形態を前提とする。 ## 提案手法 **Figure 1: 単一のホスト内ボトルネックが分散機械学習システム全体のスループットを70%低下させる** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig01-single-bottleneck-throughput.png]] (Figure 1. 8ホストによる ring-based NCCL all-reduce テストで、各ホストが200Gb/s RNICを持つ構成において、あるRNICのPCIeリンクが帯域劣化を起こした結果、全ホストのスループットが正常時(上側の線、約185Gbps)から約50Gbpsへ約70%低下した実測例。Source: Adapted from Figure 1.) ### 背景: ホスト内ボトルネックの2症状とRNICネットワーク問題の1症状 著者らの長期トラブルシューティング経験に基づき、ホストネットワーク問題は次のように整理される。 - **ホスト内帯域劣化**とホスト内**レイテンシ増加**——リンク障害・トラフィック輻輳・誤設定(ACS 有効化等)により生じる。詳細は [[ホスト内ネットワークボトルネック]] を参照。 - **RNIC ネットワーク問題の共通症状は接続性問題**——ルーティング設定の欠落や RNIC のフラッピングにより、あるRNICが他のRNICとRDMA通信できなくなる。これは NSDI 版では詳述されなかった、本論文で強調される第3の症状カテゴリである。 **Figure 2: 評価環境のホストトポロジ** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig02-host-topology.png]] (Figure 2. 著者らの最も複雑な訓練用ホストのトポロジ。2基の Intel Xeon CPU が Intel UPI で接続され、各 CPU root complex に4基の Nvidia A100 GPU と2基の Mellanox CX6-DX 200Gb/s RNIC が複数の PCIe スイッチ経由でぶら下がる。①〜⑤は著者らが実際に遭遇したリンク障害(RNIC PCIe・GPU PCIe・CPU root port・メモリチャネル・UPI)、⑥はトラフィック輻輳によるホスト内帯域劣化を示す。Source: Adapted from Figure 2.) **Figure 3: リンク障害とトラフィック輻輳の両方がホスト内帯域劣化を招く** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig03-link-failure-contention.png]] (Figure 3. 左: PCIe ダウングレード発生時、スループットが正常時 197.0 Gbps から 67.0 Gbps に低下し、Tx pause duration ratio が 0% から 35.7% へ急増する。右: トラフィック輻輳発生時、スループットが 150.0 Gbps に低下し pause duration ratio が 24.7% となる。Source: Adapted from Figure 3.) **Figure 4: GDR read 距離の増加に伴うレイテンシ上昇とスループット低下** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig04-gdr-distance-latency.png]] (Figure 4. 左: ホストレイテンシは距離❶(単一PCIeスイッチ経由)で 1.0µs、距離❸(CPU root complex経由)で 2.2µs、距離❹(UPI経由)で 2.4µs に増加する。右: 対応するスループットは 195.0 Gbps → 125.5 Gbps → 116.4 Gbps と低下する。わずか1.4µsの追加レイテンシが約40%のスループット低下をもたらす。Source: Adapted from Figure 4.) ### アーキテクチャ Hostping エージェントは RDMA サーバ上に配置され、3コンポーネントで構成される。 - **Hardware Monitor**: ホストの稼働状況(RNIC スループット・GPU 状態)と RNIC 上の異常メトリクス(Tx pause frame・パケットドロップ)を監視し、いつ Hostping Engine を起動するかを判断する。 - **Hostping Engine**: 3つの機能を持つ——(1) ループバックテストによるホスト内レイテンシ・帯域の測定、(2) R2R probing による各 RNIC の接続性評価、(3) バス使用率(PCIe リンク・ソケット間バス・メモリチャネル)の監視。 - **Data Analyzer**: Hostping Engine が収集したデータをもとに、ホスト内ボトルネックと RNIC ネットワーク問題の両方を判定・診断する。全モジュールの収集情報はクラウドのデータストレージ(時系列DB)へアップロードされ、後続の診断や履歴分析の基盤となる。 **Figure 5: Hostping の核となるアイデア(ループバックテスト + R2R probing)** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig05-hostping-core-idea.png]] (Figure 5. RNIC とホスト内エンドポイント(GPU・メモリノード)の間でループバックテストを行いホスト内レイテンシ・帯域を測定する(赤の破線)のに加え、同一ホスト上の RNIC 同士が相互にプローブする R2R probing(黒の破線)を行う概念図。ループバックテストは全てホスト内で完結しネットワークへは出ないが、R2R probing はホスト間ネットワーク(ToR スイッチ)を経由する点が異なる。NSDI 版の Figure 5 には無かった R2R probing が追加されている。Source: Adapted from Figure 5.) **Figure 6: Hostping のフレームワーク** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig06-hostping-framework.png]] (Figure 6. Hostping Agent(Hardware Monitor・Hostping Engine・Data Analyzer)が Cloud Data Storage へ「異常メトリクス」「メトリクス」「問題(Problems)」を段階的にアップロードする全体構成。Hardware Monitor は Host Status/RNIC Metrics に応じ Idle または Abnormal のトリガーで Hostping Engine(Active Probing・Bus Monitor)を起動し、Hostping Engine のメトリクスを Data Analyzer が Problem Diagnosis に変換する。Source: Adapted from Figure 6.) ### アルゴリズム/手法の詳細 **ループバックテストによるレイテンシ・帯域測定**: Hostping Engine は `ibv_reg_mr` でエンドポイント上に read/write 用の2つのメモリ領域を登録し、`ibv_post_send` で write WQE(RNIC に対し read region から指定サイズのメッセージを読み write region へ書き戻すよう指示)を投げる。RNIC は read region から読み取り、送信者・受信者が同一 RNIC であるためネットワークへは送出せず直接 write region へ書き戻す。`ibv_post_send` 呼び出しから completion のポーリングまでの時間差からループバックレイテンシを算出する。 $Lat = T_{proc} + Lat_{host} + \frac{Size}{BW_{host}} \quad (1)$ $T_{proc}$ は (1) `ibv_post_send` 呼び出しから RNIC が最初の read request を送出するまでの時間と、(2) 全 PCIe write packet 送出完了から CPU が completion をポーリングするまでの時間の合計。$BW_{host}$ は PCIe read/write のうち小さい方の帯域。小メッセージ(1バイト)を使うと式(1)は $T_{proc} + Lat_{host}$ に近似でき(式2)、大メッセージ(200Gb/s RNIC 向けに256KB)を使うと $Size / BW_{host}$ に近似できる(式3)。実際には大小メッセージのレイテンシ差分(式1−式2)を取ることで式3を得るため、非常に大きなメッセージを使う必要はない。 **Figure 7: ループバックテストの処理過程** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig07-loopback-test-timing.png]] (Figure 7. Hostping Engine が `ibv_post_send` の呼び出しから completion のポーリングまでの区間を測定してループバックレイテンシを算出する過程。Doorbell → Fetch WQE → Read Request → Message → Write という一連のステップと、$T_{proc}$・$Lat_{host}$・$Size/BW_{host}$・$T_{proc}$ の内訳を示す。Source: Adapted from Figure 7.) **R2R probing による RNIC 接続性測定**(本論文で新規に定式化された機構): ホスト上の各 RNIC は周期的に小さな RDMA パケットを構築し、同一ホスト上の他の RNIC のうち1台をランダムに選んでプローブする。対象 RNIC は ACK パケットで応答する。送信側 RNIC がタイムアウト閾値内に ACK を受信すれば成功、そうでなければタイムアウトと記録する。R2R probing は ToR スイッチの配下で行われるため、RNIC A から RNIC B へのプローブがタイムアウトした場合、原因は A・B・ToR スイッチのいずれかにありうる——Hostping はこれらをまとめて「RNIC ネットワーク問題」として扱う(全 RNIC へのプローブが同時にタイムアウトする極端なケースは ToR スイッチ自体の異常である可能性が高いと推定する)。プローブのペイロードサイズはサービスへの負荷を抑えるため1バイトとする。 **アルゴリズム1(リンク障害検出、binary network tomography に着想)**: ホストがアイドル時、Hostping は RNIC と各エンドポイント間で full-mesh ループバックテストを行い、パス(path)ごとの正常・異常を判定する。 $y_j = \prod_{i:\ link_i \in path_j} x_i, \quad \forall j \quad (4)$ $x_i, y_j \in \{0,1\}$(1が正常)でパス $j$・リンク $i$ の状態を表す。アルゴリズムは次の手順で全リンクを分類する: (1) 全リンクを `uncertain` に初期化する。(2) 正常パス上の全リンクを `normal` にマークする。(3) 異常パス上に `uncertain` のリンクがあれば、それらを `abnormal` にマークし `abnormal_cnt` を1増やす。異常パス上に既に `abnormal` のリンクがあり、かつ新たな RNIC がそのリンクを異常と判定した場合も `abnormal_cnt` を増やす。(4) 異常パスの全リンクが `normal` の場合、それらのリンクを `gray`(フラッピング疑い)にマークする。3回連続で `gray` と判定されたリンクは flapping link と確定する。 **バス使用率監視**: ループバックテストだけでは、あるリンクの帯域劣化がトラフィック輻輳によるものかリンク障害によるものか判別できない場合がある。そこで Bus Monitor が PCIe リンク・ソケット間バス・メモリチャネルの使用率を監視し、リンクが過負荷(閾値 $Util_{high}$ 超)であれば輻輳、そうでなければリンク障害と推定する。ベンダー固有ツール(Intel PCM・AMD uProf・Nvidia SMI 等)に依存せず、異なるベンダーのデバイスに自動的に適応する。 **サービストラフィック干渉下の診断**: ホストが混雑時(異常メトリクスによりトリガーされた場合)は、RNIC とその affinitive エンドポイント(同一 root port 配下のメモリノード・GPU)間のみを対象にループバックテストを行う。affinitive エンドポイント間の帯域はサービストラフィックの影響下でも通常ほぼ同一のはずなので、ある宛先だけ帯域が閾値 $Abnormal_{th}$ 以上低ければそのパスを異常と判定する。同一 root port 配下のリンクについては、その異常 RNIC のみを使って状態を判定する(他の RNIC が測定した同一リンクへの帯域は、affinitive GPU 経由のサービストラフィックの影響を受けて不正確になりうるため)。 **R2R probing による RNIC ネットワーク問題の診断**: Data Analyzer は R2R プローブ結果を周期的(20秒粒度)に集計し、各 RNIC へのタイムアウト率を算出する。タイムアウト率が閾値 $Timeout_{th}$(10%)を超えた RNIC を「ネットワーク問題あり」と判定する。継続的に100%タイムアウトする RNIC(到達不能)の根本原因は典型的に RNIC ダウンまたはルーティング誤設定であり、突発的なタイムアウトの根本原因は典型的に RNIC ハードウェア障害(フラッピング等)である。 ### 実装上の工夫 - Hardware Monitor は5分ごとにホストステータスを確認し(リンク障害・設定ミスは低頻度なので5分粒度で十分と判断)、1秒ごとに異常メトリクスを収集する。 - 閾値: $Thp_{low}$(RNIC アイドル判定)は line rate の 5%、$PFC_{high}$(異常トリガー、毎秒30msのポーズに相当)は 3%、ループバックテストの $Abnormal_{th}$(パス異常判定)は 20%、$Util_{high}$(バス過負荷判定)は 90%、R2R probing の分析粒度は 20 秒、$Timeout_{th}$(RNIC 問題判定)は 10%。 - R2R probing の各 RNIC のプローブ間隔は 100ms(100ms スケールの問題を捕捉するため)、各プローブのタイムアウトは 500ms。 - GPU 状態は Nvidia Management Library(NVML)、CPU root port・メモリチャネル・ソケット間バスの計測は Intel/AMD の API、RNIC PCIe リンクは Mellanox の指標を使用し、ベンダーごとに実装を切り替える。 - probing モジュールは verbs API と rdma-core ライブラリで実装。 - クラウド側のデータストレージは時系列データベースで実装され、Hostping Engine 起動のたびに収集・推論データがアップロードされる。 ## 新規性 既存のボトルネック診断ツールは Intel PCM(Intel CPU 用)・AMD uProf(AMD CPU 用)・Nvidia SMI(Nvidia GPU 用)・Mellanox Neohost(Mellanox RNIC 用)のようにベンダー固有であり、複数ベンダーの組み合わせを持つホストでは複数ツールの学習・運用コストが発生する(fragmented)。ホスト内ネットワークに特化した監視・診断システムはこれまで存在せず(unresponsive)、perftest・nccl-test のような end-to-end ベンチマークではホスト内かネットワーク側かを即座に切り分けられない(time-consuming)。 NSDI '23 版からの拡張点として、本論文は次を追加する: (1) RNIC 自体の接続性問題(ルーティング誤設定・フラッピング・誤配線)を、ホスト内ボトルネックとは別の症状カテゴリとして扱い、R2R probing という低オーバーヘッドな機構(コントローラ不要で各ホストが自律的に実行可能)で診断する。(2) リンク状態推論を Algorithm 1 として形式化し、binary network tomography との対応関係を明示する。(3) RDMA verb 呼び出しエラーの検知やコンテナ環境での運用など、実運用上の追加知見(Section VII)を報告する。 ## 実験設定 - **環境**: 数千台の本番分散機械学習システムの RDMA サーバ。評価に用いた最も複雑なホストトポロジは Figure 2(2基の Intel Xeon CPU、UPI 接続、各ソケットに4基の Nvidia A100 GPU + 2基の Mellanox CX6-DX 200Gb/s RNIC)。 - **比較対象**: 論文内に明示的な baseline ツールとの定量比較実験は記載されていない(ベンダー固有ツールとの機能比較が定性的に述べられる)。 - **評価指標**: ホスト内帯域(Gbps)、ホスト内レイテンシ(µs)、Tx pause duration ratio(%)、bandwidth matrix(RNIC×エンドポイントの正常/異常/uncertain の色分け行列)、R2R probing のタイムアウト率(%)。 ## 実験結果 Hostping を数千台の本番サーバへ展開した結果、既知の問題を数分で検知・診断できただけでなく、8種の新規問題([New] とマークされた #5・#6・#8・#9・#11・#12・#14・#16)を発見した。 **Figure 8: アイドル時のホスト間帯域行列(6パターン)** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig08-bandwidth-matrices-idle.png]] (Figure 8(a)-(f). ホストがアイドル時に Hostping Engine が計測したホスト内 end-to-end 帯域行列。緑=正常、赤=異常、灰=不確実。(a) #1 RNIC PCIe リンク障害。(b) #2 GPU PCIe リンク障害と #3 メモリチャネル障害の合成例(誌面の制約により1枚にまとめている)。(c) #4 UPI 障害。(d)(e) [New] #5 CPU ルートポート障害——ルートポート自体との直接パスは正常だが、そのルートポートを経由するパスが劣化する((e)はより軽微な劣化)。(f) [New] #7 ACS 有効化による誤設定——同一 root port 配下の RNIC-GPU 間で帯域・レイテンシが共に異常化する。Source: Adapted from Figure 8.) **Figure 9: メモリチャネルのフラッピング** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig09-memory-channel-flapping.png]] (Figure 9. [New] #6 あるサーバでメモリチャネル帯域が正常(Normal、約200Gbps)と異常(Flapping、50〜150Gbps程度まで乱高下)を継続的に切り替える現象(2021年12月15日の実測)。単発の手動テストでは発見できず、Hostping を継続的に実行して初めて根本原因がフラッピングするメモリチャネルにあると特定できた。Source: Adapted from Figure 9.) **シナリオ1: リンク障害による帯域劣化**: 展開中に、#1 RNIC PCIe リンク・#2 GPU PCIe リンク・#3 メモリチャネル・#4 UPI の障害による帯域劣化を数十件発見した。[New] #5 CPU ルートポート障害(該当ルートポート自体との直接パスは正常だが、それを経由する他のパスが劣化する。ソフトウェアバグまたはマザーボード故障が原因で、ホスト再起動またはマザーボード交換が必要)と、[New] #6 メモリチャネルフラッピング(継続的な監視でのみ発見可能)を確認した。 **シナリオ2: 誤設定による性能劣化**: #7 ACS(Access Control Service)有効化により GDR トラフィックが GPU へ直接届かず CPU へ迂回する事例(II-A 節で既述)。[New] #8 仮想化環境で ATS(Address Translation Service)を無効化すると、GDR パケットのアドレス変換のため全て CPU root complex を経由させられ、同一 root port 配下の RNIC-GPU 間レイテンシが増加する事例(ATS 有効化で最適な GDR 性能に戻る)。 **シナリオ3: トラフィック輻輳による帯域劣化**: [New] #9 ソケット間バス(UPI)の過負荷——誤動作するアプリケーションがホストの UPI を占有し、RNIC0 の cross-socket 受信トラフィックが大量の Tx pause frame を誘発した事例。RNIC0・RNIC2 に大量のサービストラフィックがあっても、他の測定パスとの比較でUPIが最も疑わしい(`abnormal_cnt` が最大)と判定できた。#10 メモリチャネルの過負荷——A100 サーバの本番展開では自然発生を観測しなかったため、複数プロセスで mem0 チャネルを人為的に輻輳させる補足実験を実施し、RNIC0・RNIC2 に大量の受信トラフィックがあってもmem0への異常パスを検出できることを確認した。 **Figure 10: 混雑時のホスト間帯域行列** ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig10a-gpu-pcie-link-failure.png]] ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig10b-upi-overload.png]] ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig10c-memory-channel-overload.png]] (Figure 10(a)-(c). ホストがサービストラフィックで混雑している状態で計測した帯域行列。(a) GPU PCIe リンクのハードウェア障害(RNIC2-GPU4間が赤)。(b) UPI の過負荷(#9)——RNIC0-Mem1・RNIC2-Mem0 の2パスが異常化。(c) メモリチャネル mem0 の過負荷(#10)——RNIC0・RNIC2 からの mem0 への全パスが異常化。Source: Adapted from Figure 10.) **シナリオ4(RNIC ネットワーク問題): 接続性失敗**: #13 異常な RNIC ルーティング設定——ルーティング設定が欠落した RNIC は他の RNIC と RDMA 通信できず、R2R probing の集計結果でタイムアウト率が継続的に100%となる。[New] #14 一部の RNIC が誤ったスイッチポートに接続されていた事例——あるホストの全 RNIC へのプローブタイムアウト率が約2/3で高止まりしていたことをきっかけに調査したところ、RNIC0/RNIC1 同士・RNIC2/RNIC3 同士は通信できるが RNIC0/1 と RNIC2/3 の間は通信できず、原因は RNIC2・RNIC3 が異なるサブネットに属する誤ったスイッチポートに接続されていたことだった。 **シナリオ5(RNIC ネットワーク問題): ハードウェア障害によるパケットドロップ**: #15 RNIC フラッピング——RNIC・スイッチ・ケーブルの型番不一致が根本原因であることが長期分析で判明し、ケーブル交換でフラッピング頻度が大幅に減少した。[New] #16 RNIC での頻繁なビット誤り(bit jumps)——送受信パケットに大量の破損とパケットドロップを引き起こす現象で、劣化・経年したケーブルまたは光モジュールが原因であり、ケーブルまたは RNIC の交換で解決する。 ## 考察 - **binary network tomography の応用**: Hostping のリンク状態推論(Algorithm 1)は binary network tomography(Cunha+ 2009, Duffield 2006)に着想を得ており、パス単位の観測から個々のリンク状態を逆算する枠組みをホスト内トポロジへ適用した点が特徴的である。 - **能動探索とパッシブ監視の使い分け**: アイドル時は full-mesh ループバックテストでオーバーヘッドを気にせず網羅的に診断できるが、混雑時は affinitive エンドポイントとの相対比較および Bus Monitor の使用率情報を組み合わせることで、サービストラフィックの影響下でも診断精度を維持する。 - **RDMA verb 呼び出しエラーの検知**(TNET版で追加): Hostping はサービスアプリケーションが一般的に使用する RDMA verb(QP 作成・メモリ登録等)を自ら呼び出すため、ドライバやカーネルモジュールの欠落に起因する verb 呼び出しエラーを事前に検知できる。verb 実行時間を計測することで、GPU メモリ登録の高レイテンシ(GPU 障害が原因になりうる)のようなボトルネックも検知できる。 - **コンテナでの実行**(TNET版で追加): 分散訓練タスクは物理マシン上のコンテナで実行されることが多く、Hostping もコンテナ内で実行することで、異なる物理マシン環境への適応コストを削減できる。継続実行に加え、一定期間だけループバックテストと R2R probing を実行して問題有無を判定する「single-run」コンテナも用意されている。 - **限界**(TNET版で追加): Hostping が検知できるのは外因的(extrinsic)な問題(障害・誤設定・トラフィック輻輳)に限られる。IOMMU・DDIO(Data Direct I/O)のようなホスト内在的(intrinsic)な問題や、RNIC ハードウェアネットワークスタック・RNIC ハードウェアリソース・RNIC 性能分離といった RNIC 内在的な問題は対象外であり、著者らは今後 Lumina・Husky・Justitia 等の既存手法をこれらの内在的問題の発見に活用したいとしている。 - **運用上の教訓(Experiences Learned、Section VII)**: (1) サーバ出荷時に既にリンク障害が存在しうるため、稼働開始前・再起動後に Hostping を実行すべきと提言する(ACS はリブート不要で再設定が必要、ATS はリブートが必要、という設定項目ごとの差異にも言及)。(2) 輻輳制御機構自体がホスト内ボトルネックを知覚できるよう、最新の RNIC が提供する VoQ(Virtual Output Queuing)ECN marking(受信バッファ閾値超過時に受信側 RNIC が ECN マークする機能)を活用し、DCQCN のような ECN ベースの輻輳制御と組み合わせるべきだと主張する。(3) GDR は CPU root port を跨ぐ経路を避けるべきであり、AMD サーバでは remote socket のメモリと RNIC の通信(cross-socket 帯域が低い)を避けるべきとの経験則を共有する。 ## 強み / 弱点・課題 **強み**: - ベンダー非依存(commodity RNIC ベース)で全 RDMA サーバに低オーバーヘッドで展開可能。 - ホスト状態(busy/idle)と異常メトリクスに応じてプロービング頻度を動的調整し、応答性とオーバーヘッドをトレードオフする設計。 - ホスト内ボトルネックと RNIC ネットワーク問題という2種類の問題を、ループバックテストと R2R probing という2つの軽量な機構で統一的にカバーする。 - 数千台規模の本番展開という大規模な実運用データに基づき、計8種の新規問題を具体的に報告している。 **弱点・限界(著者ら自身の記述)**: - ホストが busy な状態では、サービストラフィックの影響により二値のパス状態だけでは正確なリンク状態診断が難しい。end-to-end のトラフィック情報が得られればより正確な診断が可能になると今後の課題としている。 - 過負荷リンクを発見した後、トラフィック源(誤動作アプリケーション等)を自動的に特定する機能はまだない(オペレータの追加調査が必要)。 - R2R probing はタイムアウトが RNIC・RNIC リンク・スイッチポートのいずれに起因するかを直接切り分けられず、これらをまとめて「RNIC ネットワーク問題」として扱う。 - IOMMU・DDIO のようなホスト内在的な問題や RNIC ハードウェア内在的な問題は対象外(§考察の限界を参照)。 - 定量的な baseline 比較実験(他ツールとの精度・オーバーヘッド比較)は提示されておらず、本番展開での定性的な事例報告が中心。