> [!abstract] 概要(arXiv abstract の日本語訳) > ホスト内ネットワーキングは、これまで RDMA(Remote Direct Memory Access)ネットワークにおいて頑健だとみなされ、ほとんど注目されてこなかった。しかし RNIC(RDMA NIC)の線速が数百ギガビット規模へ急速に増加するにつれ、ホスト内ネットワークはネットワークアプリケーションにとって潜在的な性能ボトルネックになりつつある。ホスト内ネットワークのボトルネックは、ホスト内帯域の劣化とホスト内レイテンシの増加を引き起こし、ネットワーク性能を著しく損なう可能性がある。しかし、ホスト内ボトルネックが発生しても、監視システムの欠如によりほとんど気づかれない。さらに、既存のボトルネック診断機構はホスト内ボトルネックを効率的に診断できていない。本論文では、われわれの長期にわたるトラブルシューティング経験に基づきホスト内ボトルネックの症状を分析し、ホスト内ネットワークに特化した最初のボトルネック監視・診断システムである Hostping を提案する。Hostping の核となるアイデアは、ホスト内の RNIC とエンドポイントの間でループバックテストを実施し、ホスト内レイテンシと帯域を計測することである。Hostping は、われわれが既に把握していたホスト内ボトルネックを発見するだけでなく、これまで気づいていなかった6件のボトルネックも明らかにした。 ## 論文情報 - タイトル: Hostping: Diagnosing Intra-host Network Bottlenecks in RDMA Servers - 著者: Kefei Liu†(BUPT)・Zhuo Jiang§(ByteDance Inc.)・Jiao Zhang†‡(BUPT and Purple Mountain Laboratories、責任著者)・Haoran Wei†§(BUPT and ByteDance Inc.)・Xiaolong Zhong†(BUPT)・Lizhuang Tan§(ByteDance Inc.)・Tian Pan†‡・Tao Huang†‡(BUPT and Purple Mountain Laboratories) - 媒体: 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI '23)、2023年4月17〜19日、Boston, MA, USA - Kefei Liu・Haoran Wei・Xiaolong Zhong は ByteDance との共同研究プロジェクトとして本研究を実施(第一著者2名は同等貢献)。 - コード・DOI: 論文中に明記なし。 ## 概要 RNIC の線速が急速に向上する一方、PCIe をはじめとするホスト内帯域の伸びがそれに追いつかず、ホスト内ネットワーク(PCIe リンク・メモリチャネル・ソケット間バス)が RDMA 通信の新たなボトルネックになりつつあるという問題意識のもと、著者らはホスト内の RNIC-エンドポイント間ループバックテストによりホスト内帯域・レイテンシを計測し、ボトルネックを検知・診断する Hostping を提案する。300台超の本番分散機械学習サーバへの展開を通じて、既知のリンク障害に加え、CPU ルートポート障害やメモリチャネルフラッピングなど、Hostping なしでは気づけなかった6種の新規ボトルネックを発見したと報告する。 ## 問題設定 - **入力**: RDMA サーバのホスト内トポロジ(RNIC・GPU・メモリノード・PCIe スイッチ・CPU ソケット間の物理接続)、および RNIC の稼働状況(スループット、Tx pause frame 比率、パケットドロップ)。 - **出力**: ホスト内の各リンク(RNIC PCIe リンク・GPU PCIe リンク・メモリチャネル・CPU ルートポート・UPI/QPI)の正常・異常判定と、異常時の推定根本原因(リンク障害・トラフィック輻輳・設定ミス・フラッピング)。 - **前提条件**: RDMA が有効な commodity RNIC(`ibv_reg_mr` / `ibv_post_send` 等の verbs API が使えること)。ホストが busy/idle を行き来するデータセンター運用形態を想定する。 ## 提案手法 **Figure 1: 単一のホスト内ボトルネックが分散機械学習システム全体のスループットを70%低下させる** ![[_attachments/nsdi23-liu-kefei/fig01-single-bottleneck-throughput.png]] (Figure 1. 8ホストによる ring-based nccl all-reduce テストで、各ホストが200Gb/s RNICを持つ構成において、あるRNICのPCIeリンクが帯域劣化を起こした結果、全ホストのスループットが正常時(上側の線、約185Gbps)から約50Gbpsへ約70%低下した実測例。1本のホスト内ボトルネックが分散システム全体の性能を左右することを示す動機付けの図。Source: Adapted from Figure 1.) ### 背景: ホスト内ボトルネックの2症状 Hostping の核心は、長期トラブルシューティング経験から「ほとんどのホスト内ボトルネックは、ホスト内帯域劣化とホスト内レイテンシ増加のいずれか、または両方の症状を示す」と見抜いた点にある。 - **帯域劣化**: リンク障害または他トラフィックによる占有でホスト内帯域が RNIC 受信レートを下回ると、RNIC 受信バッファが蓄積する。lossy 環境(PFC 無効)ではパケットドロップに、lossless 環境では Tx pause frame の送出(ひいては PFC storm)につながる。ACS(Access Control Service)を有効化すると GDR(GPU Direct RDMA)トラフィックが全て CPU へ迂回させられ、ホスト内レイテンシの急増と帯域の著しい劣化を招く典型例として挙げられている。 - **レイテンシ増加**: RNIC がエンドポイントへ PCIe read request TLP を送ってからデータが返るまでの往復時間が伸びると、line rate を維持するためにより多くの outstanding read request が必要になるが、RNIC には上限があるため帯域が劣化する。GDR トラフィックが CPU root complex を経由する距離(¶単一PCIeスイッチ→·複数PCIeスイッチ→¸CPU root complex→¹UPI)が長いほどレイテンシが増加する実測を Figure 4 で示しており、わずか 1.4 µs の追加レイテンシがホスト内帯域を 40% 低下させたと報告する。 **Figure 2: 評価環境のホストトポロジ** ![[_attachments/nsdi23-liu-kefei/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/nsdi23-liu-kefei/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% となる。両者とも RNIC のスループットを絞り、大量の PFC pause frame を誘発する。Source: Adapted from Figure 3.) **Figure 4: GDR read 距離の増加に伴うレイテンシ上昇とスループット低下** ![[_attachments/nsdi23-liu-kefei/fig04-gdr-distance-latency.png]] (Figure 4. 左: ホストレイテンシは Distance 1(単一PCIeスイッチ経由)で 1.0µs、Distance 3(CPU root complex経由)で 2.2µs、Distance 4(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**: (1) RNIC を用いてホスト内レイテンシ・帯域を計測する Active Probing 機能と、(2) PCIe リンク・ソケット間バス・メモリチャネルのバス使用率を監視する Bus Monitor 機能を持つ。 - **Data Analyzer**: Hostping Engine が収集したデータをもとに、ホスト内にボトルネックが存在するか判定し、根本原因を診断する。全モジュールの収集情報はクラウドのデータストレージ(時系列DB)へアップロードされ、後続の診断や履歴分析の基盤となる。 **Figure 5: Hostping の核となるアイデア(ループバックテスト)** ![[_attachments/nsdi23-liu-kefei/fig05-core-idea-loopback.png]] (Figure 5. RNIC とホスト内エンドポイント(GPU・メモリノード)の間でループバックテストを行い、ホスト内レイテンシと帯域を測定する概念図。全通信はホスト内で完結し、ネットワークへは出ない。Source: Adapted from Figure 5.) **Figure 6: Hostping のフレームワーク** ![[_attachments/nsdi23-liu-kefei/fig06-hostping-framework.png]] (Figure 6. Hostping Agent(Hardware Monitor・Hostping Engine・Data Analyzer)が Cloud Data Storage へ「異常メトリクス」「メトリクス」「ボトルネック」を段階的にアップロードする全体構成。Hardware Monitor は Host Status/RNIC Metrics に応じ Idle または Abnormal のトリガーで Hostping Engine(Active Probing・Bus Monitor)を起動する。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)、大メッセージ(128KB、200Gb/s RNIC 向け)を使うと $Size / BW_{host}$ に近似できる(式3)。実際には大小メッセージのレイテンシ差分(式1−式2)を取ることで式3を得る。 **Figure 7: ループバックテストの処理過程** ![[_attachments/nsdi23-liu-kefei/fig07-loopback-test-process.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.) **バス使用率監視**: ループバックテストだけでは、あるリンクの帯域劣化がトラフィック輻輳によるものかリンク障害によるものか判別できない場合がある。そこで Bus Monitor が PCIe リンク・ソケット間バス・メモリチャネルの使用率を監視し、リンクが過負荷(閾値 $Util_{high}$ 超)であれば輻輳、そうでなければリンク障害と推定する。ベンダー固有ツール(Intel PCM・AMD uProf・Nvidia SMI 等)に依存せず、異なるベンダーのデバイスに自動的に適応する点を特徴とする。 **アルゴリズム1: リンク障害検出(binary tomography に着想)**: ホストがアイドル時、Hostping は RNIC と各エンドポイント間で full-mesh ループバックテストを行い、パス(path)ごとの正常・異常を判定する。式(4) $y_j = \prod_{i: link_i \in path_j} x_i$ でパス $j$ の状態はそのパス上の全リンクの積として表される($x_i, y_j \in \{0,1\}$、1が正常)。正常パス上のリンクは全て正常とマークし、異常パス上のリンクは(既に正常でない限り)異常とマークして `abnormal_cnt` をインクリメントする。全リンクが正常なのにパスが異常なら「フラッピング」の可能性ありとしてリンクを gray とマークし、3回連続で gray なら flapping link と確定する。 **サービストラフィック干渉下の診断**: ホストが混雑時(異常メトリクスによりトリガーされた場合)は、RNIC とその affinitive エンドポイント(同一 root port 配下のメモリノード・GPU)間のみを対象にループバックテストを行う。affinitive エンドポイント間の帯域はサービストラフィックの影響下でも通常ほぼ同一のはずなので、ある宛先だけ帯域が閾値 $Abnormal_{th}$(20%)以上低ければそのパスを異常と判定する。この場合、影響を受けた RNIC 以外にアイドルな RNIC があればベースラインとの比較も併用し、診断精度を補う。 ### 実装上の工夫 - Hardware Monitor は5分ごとにホストステータスを確認し、1秒ごとに異常メトリクスを収集する(リンク障害・設定ミスは低頻度なので5分粒度で十分と判断)。 - 閾値: $Thp_{low}$(RNIC アイドル判定)は line rate の 5%、$PFC_{high}$(異常トリガー)は 3%(毎秒 30ms のポーズに相当)、$Abnormal_{th}$(パス異常判定)は 20%、$Util_{high}$(バス過負荷判定)は 90%。 - GPU 状態は Nvidia Management Library(NVML)、CPU root port・メモリチャネル・ソケット間バスの計測は Intel/AMD の API、RNIC PCIe リンクは Mellanox の指標を使用し、ベンダーごとに実装を切り替える。 - probing モジュールは verbs API と rdma-core ライブラリで実装。 ## 新規性 既存のボトルネック診断ツールは 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)。 Hostping はこれら3つの限界に対し、(1) commodity RNIC ベースのループバックテストによりベンダー非依存で全ホストに展開可能とし(deployability・scalability)、(2) ホストの busy/idle 状態と RNIC の異常メトリクスに応じてプロービング頻度を動的に調整することで低オーバーヘッドと応答性を両立し(responsiveness・lightweight)、(3) サービストラフィックの干渉下でも affinitive エンドポイント比較とバス使用率監視を組み合わせて根本原因を診断できる点で従来手法と異なる。 ## 実験設定 - **環境**: 300台超の本番分散機械学習システムの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 の色分け行列)。 ## 実験結果 Hostping を300台超の本番サーバへ展開した結果、既知の4種のリンク障害(#1 RNIC PCIe リンク、#2 GPU PCIe リンク、#3 メモリチャネル、#4 UPI)を効果的に診断できただけでなく、以下6種の新規ボトルネックを発見した。 **Figure 8: アイドル時のホスト間帯域行列(6パターン)** ![[_attachments/nsdi23-liu-kefei/fig08a-rnic-pcie-link-failure.png]] ![[_attachments/nsdi23-liu-kefei/fig08b-gpu-pcie-memchannel-failure.png]] ![[_attachments/nsdi23-liu-kefei/fig08c-upi-failure.png]] ![[_attachments/nsdi23-liu-kefei/fig08d-cpu-rootport-failure1.png]] ![[_attachments/nsdi23-liu-kefei/fig08e-cpu-rootport-failure2.png]] ![[_attachments/nsdi23-liu-kefei/fig08f-acs-misconfiguration.png]] (Figure 8(a)-(f). ホストがアイドル時に Hostping engine が計測したホスト内 end-to-end 帯域行列。緑=正常、赤=異常、灰=不確実。(a) RNIC PCIe リンク障害(RNIC2の全パスが異常)。(b) GPU PCIe リンク・メモリチャネル障害の合成例。(c) UPI 障害(RNIC2の遠隔ソケット側パスが軒並み異常)。(d)(e) [New] CPU root port 障害——ルートポート自体との直接パスは正常だが、そのルートポートを経由するパスが劣化する(RNIC0/RNIC3で観測、(e)はより軽微)。(f) [New] ACS 有効化による誤設定——同一 root port 配下の RNIC-GPU 間で帯域・レイテンシが共に異常化する。Source: Adapted from Figure 8.) **Figure 9: メモリチャネルのフラッピング** ![[_attachments/nsdi23-liu-kefei/fig09-memory-channel-flapping.png]] (Figure 9. [New] あるサーバでメモリチャネル帯域が正常(Normal)と異常(Flapping)を継続的に切り替える現象。単発の手動テストでは発見できず、Hostping を継続的に実行して初めて根本原因がフラッピングするメモリチャネルにあると特定できた。Source: Adapted from Figure 9.) **シナリオ1: リンク障害による帯域劣化**: 展開中に、RNIC PCIe リンク・GPU PCIe リンク・メモリチャネル・UPI の障害による帯域劣化を数十件発見した。新たに、[New] #5 CPU ルートポート障害(該当ルートポート自体との直接パスは正常だが、それを経由する他のパスが劣化する)と、[New] #6 メモリチャネルフラッピング(継続的な監視でのみ発見可能)を確認した。 **シナリオ2: 誤設定による性能劣化**: [New] #7 ACS(Access Control Service)有効化により GDR トラフィックが GPU へ直接届かず CPU へ迂回させられ、レイテンシ・帯域が共に劣化する事例。[New] #8 仮想化環境で ATS(Address Translation Service)を無効化すると、GDR パケットのアドレス変換のため全て CPU root complex を経由させられ、レイテンシが増加する事例(ATS 有効化で解消)。[New] #9 RNIC ベンダー固有の "slow start" 機能が有効化されると、送信レートが line rate でなく小さい値から開始し全エンドポイントへの帯域が baseline を下回る(当初リンク障害と誤診断したが、継続的な帯域テストで異常が見られず設定調査により判明)。[New] #10 "Tx window"(QP あたりの最大 in-flight バイト数)を小さく設定しすぎると、同様に全エンドポイントへの帯域が baseline を下回る。 **Figure 10: 混雑時のホスト間帯域行列** ![[_attachments/nsdi23-liu-kefei/fig10a-busy-gpu-pcie-failure.png]] ![[_attachments/nsdi23-liu-kefei/fig10b-upi-traffic-contention.png]] ![[_attachments/nsdi23-liu-kefei/fig10c-memchannel-traffic-contention.png]] (Figure 10(a)-(c). ホストがサービストラフィックで混雑している状態で計測した帯域行列。(a) GPU PCIe リンクのハードウェア障害(RNIC2-GPU4間が赤)。(b) [New] #11 UPI の過負荷——マルウェア的に誤動作するアプリケーションが UPI を占有し、RNIC0(Mem1宛)・RNIC2(Mem0宛)の2パスが異常化。輻輳しているにもかかわらず他の測定パスとの比較でどのRNICが異常かを絞り込めた。(c) #12 メモリチャネルの過負荷——複数プロセスで mem0 のチャネルを人為的に輻輳させた検証実験(A100サーバでは自然発生は未観測だが補足実験として実施)。Source: Adapted from Figure 10.) サービストラフィックで混雑している RNIC でも、affinitive エンドポイント間の相対比較によって「どのエンドポイントへのパスが異常か」を判定できることが Figure 10(b)(c) で示されている。 ## 考察 - **binary network tomography の応用**: Hostping のリンク状態推論(Algorithm 1)は binary network tomography(Cunha+ 2009, Duffield 2006)に着想を得ており、パス単位の観測から個々のリンク状態を逆算する枠組みをホスト内トポロジへ適用した点が特徴的である。 - **能動探索とパッシブ監視の使い分け**: アイドル時は full-mesh ループバックテストでオーバーヘッドを気にせず網羅的に診断できるが、混雑時は affinitive エンドポイントとの相対比較および Bus Monitor の使用率情報を組み合わせることで、サービストラフィックの影響下でも診断精度を維持する設計になっている。 - **運用上の教訓(Experiences Learned)**: 著者らは、(1) サーバ出荷時に既にリンク障害が存在しうるため、稼働開始前・再起動後に Hostping を実行すべきと提言する。(2) 輻輳制御機構自体がホスト内ボトルネックを知覚できるよう、VoQ(Virtual Output Queuing)ECN marking のような機能を活用し、DCQCN 等が受信バッファ超過時に ECN マークできるようにすべきだと主張する。(3) GDR は CPU root port を跨ぐ経路を避けるべきであり、AMD サーバでは remote socket のメモリと RNIC の通信を避けるべきとの経験則を共有する。 ## 強み / 弱点・課題 **強み**: - ベンダー非依存(commodity RNIC ベース)で全 RDMA サーバに低オーバーヘッドで展開可能。 - ホスト状態(busy/idle)と異常メトリクスに応じてプロービング頻度を動的調整し、応答性とオーバーヘッドをトレードオフする設計。 - 300台超の本番展開という大規模な実運用データに基づき、既知4種+新規6種、計10種のボトルネックパターンを具体的に報告している。 **弱点・限界(著者ら自身の記述)**: - ホストが busy な状態では、サービストラフィックの影響により二値のパス状態だけでは正確なリンク状態診断が難しい。end-to-end のトラフィック情報が得られればより正確な診断が可能になると今後の課題としている。 - 過負荷リンクを発見した後、トラフィック源(誤動作アプリケーション等)を自動的に特定する機能はまだない。 - 本論文はホスト内ネットワークボトルネックに焦点を当てており、RNIC 自体のスケーラビリティ問題のような RNIC ボトルネックは対象外(著者らは今後の課題として言及)。 - 定量的な baseline 比較実験(他ツールとの精度・オーバーヘッド比較)は提示されておらず、本番展開での定性的な事例報告が中心。